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Abstract 


Software  development  projects  rarely  are  started  or  proceed  without  risks  involving  the 
technologies  used.  Typically,  many  facets  of  a  project  such  as  system  functionality  and  tool 
support  depend  on  the  availability  of  a  specific  technology.  This  dependency  poses  risks:  the 
required  technology  can  disappear  within  the  project’s  life  cycle  or  a  promised  technology 
may  not  be  available  when  it’s  required. 

A  popular  software  technology  today,  Web  services  standards,  is  a  widely  supported  approach 
to  implementing  a  service-oriented  architecture.  Because  Web  services  standards  promise 
system  interoperability  and  flexibility  to  large  projects,  commercial  and  government 
organizations  are  including  it  as  the  cornerstone  of  future  computer-based  systems.  In  fact, 
many  systems  currently  being  architected  and  designed  assume  the  availability  of  products 
built  upon  a  stable  and  effective  set  of  Web  services  standards.  This  assumption  presents 
project  stakeholders  with  a  large  technology  availability  risk. 

This  technical  note  discusses  some  of  the  challenges  of  using  Web  services  standards  and 
presents  the  results  generated  by  an  assessment  tool  used  to  track  the  appropriateness  of  using 
this  technology.  The  appendix  includes  an  example  built  using  the  authors’  opinions  about 
the  current  level  of  appropriateness  of  using  Web  services  standards  in  a  typical,  large 
software-intensive  project. 


CMU/SEI-2006-TN-001 


v 


VI 


CMU/SEI-2006-TN-001 


1  Introduction 


“All  our  lauded  technological  progress — our  very  civilization — is  like  the 

axe  in  the  hand  of  the  pathological  criminal.” 

— Attributed  to  Albert  Einstein 

Addressing  and  managing  evolving  technology  in  software  development  is  a  challenge  and 
can  even  seem  to  be  an  impossible  job  when  nothing  stays  the  same  over  time.  In  this  report, 
the  evolution  of  technology  is  viewed  from  two  perspectives.  First,  software  projects  change 
over  time  due  to  modified  requirements,  fluctuating  constraints,  and  altered  designs  due  to 
implementation  decisions.  Second,  technology  selected  for  the  project  will  change,  usually 
for  reasons  beyond  the  control  of  the  project.  For  these  reasons,  software  architects, 
engineers,  and  project  managers  struggle  with  the  need  to  use  an  evolving  technology  while 
trying  to  deliver  a  project  on  schedule  and  within  budget. 

An  assessment  tool  can  be  used  to  better  understand  the  implications  of  using  an  evolving 
technology  within  the  bounds  of  a  project  that  is  itself  likely  to  change.  This  report  presents 
the  results  generated  by  an  assessment  tool  the  authors  created  for  tracking  certain  aspects  of 
an  evolving  technology,  Web  services  standards. 


1.1  Making  Decisions 

Each  of  us  needs  to  make  decisions  when  confronted  with  choices.  For  instance,  deciding 
how  to  get  from  point  A  to  point  B  could  be  daunting  if  one  were  to  consider  all  of  the 
available  modes  of  transportation.  Your  long  list  of  options  could  include  the  automobile, 
bus,  airplane,  train,  bicycle,  walking,  and  any  combination  thereof.  In  addition,  the  decision 
requires  wrestling  with  conflicting  factors  such  as  how  fast  do  I  need  to  get  to  point  B,  how 
much  will  it  cost,  what  is  my  desired  level  of  comfort,  does  my  choice  impact  the 
environment,  are  there  benefits  to  personal  health,  is  the  mode  of  transportation  enjoyable 
and  convenient,  just  to  name  a  few. 

The  decision-making  process  has  been  investigated  from  many  different  angles.  This  is 
evident  in  the  number  of  textbooks  that  discuss  decision-making.  In  the  acquisition  of 
software  products  today,  tools,  methods,  and  even  regulations  exist  in  an  attempt  to  improve 
the  overall  quality  of  software-intensive  systems  by  addressing  various  areas  in  the 
management  of  new  technology.  Deciding  when  it  is  beneficial  to  use  new  software 
technology  is  a  common  issue  throughout  the  software  development  and  acquisition 
communities.  The  following  sections  discuss  why  it  is  important  to  have  processes  and  tools 
in  place  to  help  manage  information  used  to  make  technology  decisions. 
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1.1.1  The  Challenge  of  Using  COTS  Components 

The  use  of  commercial  off-the-shelf  (COTS)  software  components  is  prevalent  throughout 
software  development  organizations  today.  In  theory,  the  reason  for  selecting  a  COTS 
software  component  is  to  use  a  proven  solution,  thus  reducing  the  overall  schedule  and  effort 
for  a  project,  while  improving  quality.  In  practice,  this  is  often  a  difficult  goal  to  achieve.  As 
discussed  in  this  report,  selecting  a  COTS  component  is  only  the  first  step  in  the  life  cycle  of 
both  the  project  and  the  technology.  Many  methods  and  approaches  are  available  to  help 
projects  evaluate  and  select  components  that  will  likely  integrate  successfully  into  the  desired 
project  [SEI  05,  Section  “Procuring  Interoperable  Components”].  Many  of  these  methods 
and  approaches  also  discuss  that  the  selection  criteria  for  COTS  components  should  go 
beyond  cost  considerations.  For  example,  evaluating  products  based  on  system  attributes 
such  as  performance,  security,  reliability  and  maintainability  improves  the  chances  for  a 
successful  project. 

In  addition  to  these  selection  issues,  dealing  with  evolving  technology  presents  an  additional 
challenge: 

Building  solutions  based  on  incorporating  pre-existing  components  is 
different  from  typical  custom  development  in  that  the  components  are  not 
designed  to  meet  a  project- defined  specification.  COTS  components  are  built 
to  satisfy  the  needs  of  a  market  segment.  Therefore,  an  understanding  of  the 
components’  functionality  and  how  it  is  likely  to  change  over  time  must  be 
used  to  modify  the  requirements  and  end-user  business  processes  as 
appropriate,  and  to  drive  the  resulting  architecture  [Albert  02]. 

This  quote  points  out  one  of  the  many  challenges  facing  practitioners.  Many  approaches 
stress  that  monitoring  the  appropriateness  of  the  selected  COTS  component  throughout  a 
product’s  life  cycle  is  necessary.  Thus,  the  need  for  a  tool  to  help  monitor  evolving 
technology  is  evident. 

1.1.2  Technology  Readiness  Assessments 

Current  Department  of  Defense  (DoD)  acquisition  directives  and  instructions  require  that 
Technology  Readiness  Assessments  (TRAs)  be  conducted  several  times  during  the  life  cycle 
of  a  product  acquisition  [DoD  03a,  DoD  03b].  A  TRA  examines  program  concepts, 
technology  requirements,  and  demonstrated  technology  capabilities  in  order  to  determine 
technological  maturity.  Maturity  is  described  through  a  “recommended  technology  readiness 
level  (TRL)  (or  some  equivalent  assessment)  for  each  critical  technology.” 

The  use  of  TRLs  enables  consistent,  uniform,  [sic]  discussions  of  technical 
maturity  across  different  types  of  technologies.  Decision  authorities  will 
consider  the  recommended  TRLs  (or  some  equivalent  assessment 
methodology,  e.g.,  Willoughby  templates)  when  assessing  program  risk. 

TRLs  are  a  measure  of  technical  maturity.  They  do  not  discuss  the 
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probability  of  occurrence  (i.e.,  the  likelihood  of  attaining  required  maturity) 
or  the  impact  of  not  achieving  technology  maturity  [DAU  04,  Section 
10.5.2]. 

The  DoD’s  Technolog y  Readiness  Assessment  (TRA)  Deskbook  describes  in  detail  how  to 
identify  the  critical  technology  for  a  project  and  evaluate  the  TRL  for  that  technology  [DoD 
05].  By  design,  TRLs  assign  a  single  value  to  make  it  easier  to  select  a  single  technology 
from  competing  technologies  by  creating  a  single  common  denominator.  Usually  when 
selecting  a  software  technology,  a  difficult  and  sometimes  frustrating  task  is  managing  the 
various  competing  attributes  of  the  whole  decision.  Smith  discusses  several  “orthogonally 
related”  attributes  that  should  be  considered  when  making  a  decision  to  utilize  a  software 
technology  [Smith  04].  These  consist  of  the  following  four  attributes: 

1.  Requirements:  How  well  the  functional  and  non-functional  requirements  can  be 
allocated  to  a  solution 

2.  Environmental  Fidelity:  How  closely  the  selected  technology  has  been  operated  in  the 
solution’s  environment 

3.  Technology  Criticality:  How  dependent  the  solution  is  on  the  selected  technology 

4.  Product  Aging:  The  lifespan  of  the  technology  related  to  the  lifespan  of  the  solution  and 
also  the  maturity  of  the  technology  in  the  marketplace 

This  report  discusses  how  using  a  subset  of  these  attributes  helps  facilitate  the  decision¬ 
making  process. 


1.2  The  Challenge  of  Assessing  Evolving  Technology 

These  examples  of  software  reuse  and  TRA  processes  show  how  important  it  is  to  gather 
information  about  a  technology  and  then  reason  and  even  experiment  to  determine  its 
appropriateness  for  use.  In  addition,  these  processes  require  that  information  be  gathered 
several  times  during  the  life  cycle  of  a  product  to  reevaluate  the  technology’s 
appropriateness.  Even  for  complex  technology,  understanding  the  functional  features  is  fairly 
straightforward.  However,  to  make  effective  choices,  decision  makers  usually  need  a  way  to 
make  the  unique  characteristics  of  the  technology  more  understandable.  Using  a  tool  to 
summarize  and  track  these  unique  characteristics  is  one  way  to  make  this  information  more 
understandable  and  usable  when  assessing  new  technologies.  These  tools  are  usually  built 
using  text  documents,  spreadsheets,  or  databases  to  make  the  information  available  and 
understandable  to  the  decision-makers. 

In  Section  2,  we  will  explore  some  of  the  decisions  that  need  to  be  made  in  large  software 
projects  using  Web  services  standards.  Section  3  describes  the  assessment  tool  used  to 
generate  the  results  presented  in  the  appendix  of  this  report.  This  tool  was  designed  to  track 
the  appropriateness  of  Web  services  standards  in  the  areas  of  requirements  and  maturity  for 
use  in  large  software  systems.  The  results  contained  in  the  appendix  are  intended  to  be  a 
starting  point  for  project  managers  and  software  architects  to  help  them  make  difficult 
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project-level  architectural  design  decisions  early  in  a  project.  Note,  however,  that  they  reflect 
a  snapshot  of  an  evolving  technology  as  of  November  2005.  In  an  attempt  to  satisfy 
stakeholders’  changing  needs  and  expectations,  assessment  tools  should  be  modified  and 
updated  frequently  to  meet  the  evolving  needs  of  the  project  and  the  current  state  of  the 
technology. 
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2  The  Challenge  of  Assessing  Web  Services  Standards 


To  assess  the  appropriateness  of  a  technology  for  use  within  a  project  requires  an 
understanding  of  the  project’s  goals  and  how  the  selected  technology  will  evolve.  This 
section  provides  some  insights  into  the  challenge  of  assessing  technology  in  general  and  Web 
services  standards  in  particular.  In  order  to  better  reason  about  the  appropriateness  of  using 
Web  services  standards  on  a  large  project  and  to  better  relate  the  methods  presented  in  this 
technical  note  to  a  real-world  situation,  we  first  introduce  a  notional  project.  We  then  look  at 
quality  attributes,  which  is  one  of  the  many  software  architectural  concepts  critical  for 
creating  successful  products.  Last,  we  discuss  how  Web  services  standards  are  created  and 
evolve. 


2.1  Language  Translation  Services  Project 

The  notional  project,  Language  Translation  Services  (LTS),  is  a  commercial  software  system 
envisioned  to  provide  thousands  of  services  worldwide,  with  thousands  of  users  who  have 
different  levels  of  system  needs.  Users  of  this  system  want  to  translate  one  or  more  words 
between  languages.  Each  service  in  the  system  is  designed  to  accept  from  1  to  1000  words  in 
one  language  and  to  return  a  message  that  contains  words  translated  into  another  language. 

To  encourage  worldwide  development  and  use,  each  service  is  limited  to  a  single  originating 
language  and  a  single  target  language.  The  data  communication  network  is  sufficient  to 
enable  the  required  communications,  but  because  of  the  distance  messages  travel  and  high 
network  traffic,  response  time  can  be  slow.  Because  of  the  need  to  interoperate  with  other 
systems  and  to  encourage  software  reuse,  the  stakeholders  have  decided  to  use  Web  services 
standards  as  a  key  design  principle. 

For  example,  the  following  scenario  can  be  used  to  reason  about  a  few  of  the  decisions  that 
need  to  be  made  for  LTS. 

The  first  part  of  a  translation  transaction  requires  a  transfer  of  1 000  English 
words  from  an  LTS  application  to  an  LTS  service  in  less  than  5  seconds  with 
a  .0001%  or  less  likelihood  of  unauthorized  viewing  of  the  data  within  50 
years. 

To  help  a  system  designer  make  tradeoff  decisions,  determining  answers  to  the  following 
questions  from  an  architectural  and  implementation  perspective  represents  large  steps  toward 
formulating  a  system  design: 

•  How  can  performance  between  an  LTS  application  and  service  across  the  worldwide 
network  be  predicted  and  monitored? 
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•  How  can  the  information  be  encrypted  so  that  both  the  LTS  application  and  service  can 
decode  it? 

•  What  does  the  LTS  application  need  to  do  to  guarantee  that  the  exact  same  information 
arrives  at  desired  LTS  service? 

•  Can  an  LTS  service  trust  that  the  received  message  is  actually  from  an  authorized  LTS 
application? 

Before  we  can  create  an  assessment  tool,  we  need  to  better  understand  the  quality  attributes 
of  a  system  such  as  LTS.  Also,  it  would  be  useful  to  understand  the  mechanisms  of  Web 
services  standards  development.  The  following  sections  discuss  quality  attributes  and  Web 
services  standards  development  and  how  they  relate  to  the  LTS  example. 


2.2  Quality  Attributes 

Software  architecture  is  an  important  phase  of  the  software  development  life  cycle.  There  are 
many  processes  and  technical  concepts  that  are  employed  to  create  and  document  a  software 
architecture.  One  architectural  concept  called  quality  attributes  is  used  in  this  report  to  help 
with  our  assessment  activity.  In  the  software  architecture  field,  quality  attributes  are 
sometimes  referred  to  as  “non- functional  requirements”  or  the  “-ilities.” 

For  example,  we  can  extract  some  quality  attributes  that  are  relevant  to  this  system  from  what 
we  know  about  the  notional  LTS  project: 

•  Reliability:  the  ability  to  make  sure  the  message  actually  gets  to  the  correct  system 

•  Performance:  the  requirement  to  move  1000  bytes  of  data  in  less  than  5  seconds 

•  Security:  make  it  highly  unlikely  that  an  unauthorized  entity  can  gain  access  to  the  data. 

Why  is  it  important  to  consider  a  system’s  quality  attributes?  Early  decisions  in  the 
architectural  process  have  an  impact  on  the  subsequent  quality  attributes  of  the  system.  As 
pointed  out  in  Software  Architecture  in  Practice,  defining  quality  attributes  is  a  crucial 
activity: 

1 .  Architecture  is  critical  to  the  realization  of  many  qualities  of  interest  in  a  system,  and 
these  qualities  should  be  designed  in  and  can  be  evaluated  at  the  architectural  level. 

2.  Architecture,  by  itself,  is  unable  to  achieve  qualities.  It  provides  the  foundation  for 
achieving  quality,  but  this  foundation  will  be  to  no  avail  if  attention  is  not  paid  to  the 
details  [Bass  03,  p.  72], 

Another  characteristic  of  quality  attributes  is  that  they  normally  compete  within  a  system  for 
dominance.  Increasing  the  prominence  of  one  quality  attribute  usually  decreases  the 
prominence  of  one  or  more  other  quality  attributes.  These  tradeoffs,  inherent  in  every  design, 
are  decisions  that  an  architect  should  share  with  all  stakeholders  throughout  the  life  cycle  of 
the  project. 


6 


CMU/SEI-2006-TN-001 


Although  there  are  many  factors  to  a  project’s  success,  understanding  the  desired  system 
quality  attributes  is  one  of  the  key  influences.  In  the  beginning  of  the  software  life  cycle, 
architecture  is  usually  considered  at  a  high  level  of  abstraction,  but  as  Bass  and  colleagues 
point  out,  high-level  decisions  need  to  be  backed  up  by  detailed  work  [Bass  03].  Focusing  on 
quality  attributes  helps  the  stakeholders  become  more  aware  of  the  ways  in  which  tradeoffs 
affect  how  the  overall  system  works. 


2.3  Web  Services  Standards 

Web  services  technology  is  being  used  industry-wide  to  implement  interoperable  service- 
oriented  architectures  (SOAs).  This  technology  comprises  a  set  of  evolving  standards  that 
tries  to  address  many  of  the  goals  and  challenges  of  the  overall  SOA  approach.  Some 
organizations  that  want  to  lower  the  cost  of  development  and  maintenance  for  software 
systems,  while  at  the  same  time  becoming  more  flexible  in  terms  of  capabilities,  consider 
Web  services  standards  as  a  possible  solution.  A  big  reason  that  SOAs  are  storming  the 
software  solution  space  is  their  key  quality  attributes  such  as  interoperability,  extensibility, 
and  modifiability  [O’Brien  05]. 

When  trying  to  predict  the  future  state  of  Web  services  standards,  it  helps  to  understand  the 
current  process  of  defining  and  implementing  them  for  use  in  solutions.  While  this  process 
can  be  fragile,  clumsy,  and  frustrating,  it  is  the  method  used  worldwide  to  develop  an  SOA 
that  interoperates  across  multiple  private  and  commercial  implementations. 

A  key  goal  of  Web  services  standards  is  to  support  interoperable  machine-to-machine 
interaction  over  a  network.  This  is  accomplished  today  by  using  Extensible  Markup 
Language  (XML)-based  messaging  such  as  Web  Services  Description  Language  (WSDL), 
the  Simple  Object  Access  Protocol  (SOAP),  and  the  Universal  Description,  Discovery,  and 
Integration  (UDDI).  These,  as  well  as  additional  standards,  are  managed  by  a  consortium  of 
industry  members.  The  process  for  developing  standards  is  open  and  evolutionary  and  as  a 
result,  the  creation  of  new  standards  and  subsequent  revisions  is  unpredictable  in  both  content 
and  timing. 

Many  organizations  are  working  to  establish  open  standards,  but  there  are  three  that  are  key 
to  the  evolution  of  Web  services  standards.  Each  of  these  three  organizations  encourages 
individual  and  organizational  membership  and  support  from  both  the  commercial  and 
academic  communities.  Members  meet  frequently  to  evolve  standards  through  defined 
processes  for  creation  of  drafts,  public  review,  and  approval  of  final  standards. 

One  of  the  key  organizations  that  develops  Web  standards  is  the  World  Wide  Web 
Consortium  (W3C1)  founded  by  Tim  Berners-Lee,  the  inventor  of  the  World  Wide  Web. 
Starting  with  the  Hypertext  Transfer  Protocol  (HTTP)  and  working  its  way  up  to  XML, 

SOAP,  and  other  standards,  this  organization  is  made  up  of  many  committees  whose  goals  are 


1  For  more  information  about  W3C,  visit  http://www.w3.org. 
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to  create  and  maintain  Web  standards  that  the  W3C  calls  “recommendations.”  Another 
group,  the  Organization  for  the  Advancement  of  Structured  Information  Standards  (OASIS2), 
is  dedicated  to  creating  the  infrastructure  and  implementation  of  Web  services  standards.  The 
other  organization  called  the  Web  Services  Interoperability  Organization  (WS-I3)  delivers 
practical  guidance,  best  practices,  and  resources  for  developing  interoperable  Web  services 
solutions.  All  three  of  these  organizations  rely  on  the  international  software  engineering 
community  including  commercial  companies,  universities,  and  individuals  to  commit  the 
knowledge  and  finances  that  allow  them  to  operate. 

At  the  time  of  this  writing,  Web  services  standards  have  a  significant  number  of  prominent 
proponents  including  Microsoft,  IBM,  Oracle,  and  BEA,  in  addition  to  the  open  source 
community  that  demonstrates  its  support  through  many  initiatives,  such  as  an  Apache 
Software  Foundation  Web  services  project  called  Axis.4  In  addition,  many  smaller 
companies,  Sonic,  Actional,  and  Systinet  to  name  a  few,  have  built  their  business  plans  by 
relying  on  Web  services  standards.  There  are  hundreds  of  other  companies  large  and  small 
that  create  software  components  built  on  interoperable  standards  and  recommendations. 

Many  of  these  companies  develop  products  that  enable  applications  to  be  built  by  integrating 
components  built  on  Web  services  standards  at  the  application  level.  The  goal  of  using  Web 
services  standards  is  to  build  a  system  by  installing  products  released  by  different  companies 
and  to  allow  the  individual  components  to  work  together  seamlessly. 

The  amount  of  activity  in  the  Web  services  standards  arena  and  wide  industry  support  lead 
one  to  believe  that  this  technology  will  be  significant  to  the  software  development  industry 
for  many  years.  One  of  the  current  problems  is  that  the  implementation  of  Web  services 
standards  is  slow  and,  at  times,  marked  by  fits  and  starts,  causing  many  adoption  headaches. 
Understanding  the  capabilities  of  each  standard  and  tracking  their  evolution  is  an  activity  that 
project  stakeholders  need  to  do  effectively  during  the  life  cycle  of  a  project.  The  next  section 
describes  a  tool  we  created  that  helps  organize  and  present  information  by  relating  the  quality 
attributes  of  a  system  with  many  of  the  more  popular  Web  services  standards. 


2  For  more  information  about  OASIS,  visit  http://www.oasis-open.org. 

3  For  more  information  about  WS-I,  visit  http://www.ws-i.org. 

4  For  more  information  about  the  Axis  project,  visit  http://ws.apache.org/axis. 
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3  Assessing  the  Appropriateness  of  Web  Services 
Standards 


As  discussed  previously,  it  is  important  to  make  decisions  about  the  appropriateness  of  a 
technology  based  on  the  quality  attributes  of  the  system.  In  the  notional  LTS  project,  the 
applications  and  services  are  based  on  Web  services  standards,  thus  creating  a  potential 
technology  risk  to  the  project.  This  risk  is  present  due  to  evolution  in  the  project’s 
implementation  and  changes  in  Web  services  standards.  The  following  sections  describe  the 
outcome  of  the  evaluation  of  this  risk  by  showing  how  we  assessed  the  appropriateness  of 
Web  services  standards  with  regard  to  impact  and  maturity  of  the  Web  services  technologies 
in  a  typical  application. 


3.1  Assessing  Appropriateness 

Below  are  a  few  situations  that  might  be  relevant  to  a  solution  using  Web  services  standards, 
such  as  the  LTS  project.  Remember  that  these  can  occur  throughout  the  product  life  cycle  in 
different  phases  and  at  unpredictable  times. 

•  Changing  expectations  overlap  with  changing  Web  services  standards. 

-  Example:  Bandwidth  increases  in  the  underlying  network  lead  users  to  expect 
improved  performance  from  the  system,  but  at  the  same  time,  standards  have  increased 
the  number  of  bytes  needed  to  send  the  same  information. 

•  A  design  decision  to  use  a  specific  standard  affects  one  or  more  quality  attributes. 

-  Example:  The  application  used  a  specific  standard  to  transfer  messages  reliably 
between  two  points.  The  standard  is  changed  to  include  an  extra  set  of  messages  to 
guarantee  accuracy,  thus  affecting  overall  performance. 

•  A  specific  standard  changes  for  reasons  beyond  the  project’s  scope,  yet  it  affects  system 

functionality. 

-  Example:  A  compression  standard  was  added  to  allow  for  efficient  transmission  over 
millions  of  miles  for  space  exploration.  This  may  have  a  positive  or  negative  effect  on 
projects  that  are  deployed  on  earth. 

In  addition  to  assessing  and  tracking  the  appropriateness  by  using  functional  requirements  or 
environmental  constraints,  evaluating  each  standard  against  a  selected  group  of  quality 
attributes  and  tracking  the  results  will  help  us  make  appropriateness  decisions  throughout  the 
LTS  life  cycle.  For  the  LTS  project,  we  assessed  and  tracked  two  dimensions  of 
appropriateness  of  Web  services  standards:  the  impact  they  have  on  the  system  quality 
attributes  and  the  maturity  of  the  standards  as  related  to  the  system  quality  attributes. 
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3.2  Selecting  Relationships  to  Assess 

The  focus  of  the  report  by  O’Brien  and  colleagues  is  to  indicate  the  impact  that  an  SOA 
approach  has  on  a  group  of  quality  attributes  of  an  application  [O’Brien  05].  An  application 
using  Web  services  standards  usually  consists  of  a  combination  of  individual  standards,  but 
the  use  of  each  standard  has  the  potential  to  impact  each  quality  attribute  of  an  application  or 
service  in  different  ways.  By  understanding  how  each  standard  affects  the  quality  attributes 
of  the  system,  the  architects,  engineers,  and  project  managers  can  make  better  assessments 
about  how  to  use  software  based  on  the  Web  services  standards.  Another  dimension  of  this 
assessment  is  the  maturity  of  a  technology.  As  discussed  earlier,  the  process  to  create  and 
evolve  each  Web  services  standard  is  volatile  and  currently  many  of  the  standards  are 
changing. 

However,  over  time  the  impact  and  maturity  dimensions  will  change.  This  occurs  because 
the  Web  services  standards,  the  project  requirements,  the  architecture,  and  the 
implementation  evolve.  As  each  standard  evolves,  changes  will  be  made  that  may  affect  the 
impact  that  it  has  on  each  of  the  quality  attributes.  For  example,  a  security  standard  that 
originally  seemed  to  have  no  impact  on  system  modifiability  could  be  changed  to  restrict 
future  architectural  changes.  Or  the  lack  of  features  within  a  standard  can  make  maintaining 
systems  that  rely  on  it  more  difficult. 

When  looking  at  a  standard’s  maturity,  it  may  seem  obvious  that  the  maturity  increases  as 
time  goes  on  or  that  monitoring  the  maturity  of  the  standard  may  seem  unnecessary  after  it 
has  been  thought  to  reach  a  mature  state.  In  reality,  both  of  these  assumptions  are  incorrect. 
A  poorly  conceived  standard  implemented  in  many  products  may  have  more  and  more 
features  added  to  it,  causing  it  to  become  unstable.  Additionally,  as  the  Web  services 
standards  improve  overall,  user  expectations  increase,  thus  requiring  expanded  support  to 
specific  standards. 


3.3  Developing  an  Assessment  Tool 

The  impact  a  Web  services  standard  has  on  a  quality  attribute  and  the  maturity  of  a  standard 
are  significant  contributors  to  the  project’s  risk  and  subsequent  mitigation  strategies.  While 
there  are  other  factors  to  consider  such  as  the  availability  and  quality  of  Web  services,  COTS 
products,  and  the  training  and  skill  level  of  available  staff,  we  have  selected  impact  and 
maturity  relationships  to  track  as  input  to  help  architects,  engineers,  and  project  managers 
make  appropriateness  assessments.  As  pointed  out  in  this  technical  note,  there  are  many 
reasons  for  the  assessments  to  be  conducted  multiple  times  during  a  product’s  life  cycle. 

The  proposed  assessment  tool  is  not  complicated,  although  the  number  of  standards  and 
quality  attributes  to  track  is  large.  For  each  standard,  13  different  quality  attributes  are 
evaluated  in  two  different  ways.  First,  the  impact  that  the  standard  has  in  relation  to  each  one 
of  these  quality  attributes  is  rated.  The  second  relationship  is  an  evaluation  of  maturity,  or 


10 


CMU/SEI-2006-TN-001 


the  likelihood  that  the  standard  will  change  in  relation  to  the  specific  attribute.  This 
determination  can  be  made  in  various  ways  ranging  from  analytical  to  empirical. 

We  started  to  track  these  relationships  in  a  spreadsheet.  Making  the  results  understandable 
and  meaningful  became  difficult  as  the  number  of  Web  services  standards  increased.  The 
spreadsheet  was  organized  into  six  pages,  with  the  standards  grouped  according  to  their  main 
function.  The  spreadsheet  format  was  effective,  but  it  was  hard  to  keep  track  of  why  each 
value  was  selected.  We  decided  to  expand  the  tool  into  a  database  containing  six  different 
tables.  In  this  way,  the  information  could  be  grouped  and  presented  in  various  reports 
allowing  the  data  to  be  visualized  and  analyzed  differently. 

Between  August  and  November  2005,  we  evaluated  Web  services  standards  at  a  high  level 
and  entered  information  into  the  database  assessment  tool.  The  results  are  contained  in  the 
appendix  of  this  report.  There  are  several  notes  of  caution  to  users  of  these  results. 

•  The  presented  results  were  prepared  to  test  the  usefulness  and  validity  of  the  assessment 
process  and  the  tool. 

•  The  assessment  value  selected  for  each  cell  was  determined  by  our  studying  the 
associated  Web  services  standard  and  making  a  “best  guess”  as  to  its  impact  and  maturity. 

•  Additionally,  the  results  include  only  our  opinions  as  of  November  2005;  further  analysis 
and  validation  through  experimentation  would  be  required  to  develop  more  accurate 
assessment. 


3.4  Selecting  a  Rating  Criteria 

Since  the  intent  of  this  exercise  was  to  evaluate  the  tool,  a  simple  three-level  rating  scale  was 
selected.  For  the  impact  dimension  the  three  levels  are  defined  as  follows: 

The  standard  tends  to  support  the  quality  attribute. 

The  standard  has  little  or  no  affect  on  the  quality  attribute. 

The  standard  tends  to  degrade  the  quality  attribute. 


Positive 

Minimal 


For  example,  a  standard  that  implements  security  related  features  would  be  assessed  as 
“positive”  in  relation  to  the  security  quality  attribute. 

The  values  of  “Mature,”  “Adolescent,”  and  “Immature”  were  selected  to  more  closely  relate 
to  the  maturity  dimension.  In  addition,  since  the  results  were  being  viewed  in  a  table,  using 
different  values  allows  the  reader  to  more  clearly  determine  which  dimension  an  individual 
cell  represents. 
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Mature 


Adolescent 


The  standard  is  widely  used  and  is  not  expected  to  change  as  related  to  the  quality 
attribute. 


The  standard  is  in  low  use  or  may  change  as  related  to  the  quality  attribute. 


The  standard  is  not  in  significant  use  or  is  likely  to  change  as  related  to  the  quality 
attribute. 


Keep  in  mind  that  a  standard  may  be  maturing  in  relation  to  certain  quality  attributes  but 
because  significant  change  is  expected  to  happen  it  may  be  less  mature  in  other  quality 
attribute  areas. 

As  a  summary  for  each  standard,  we  calculated  an  overall  impact  and  maturity  rating  based 
on  the  results  for  all  of  the  quality  attributes.  For  each  rating,  we  assigned  a  numeric  value. 
The  average  of  these  values,  which  falls  between  - 1  and  1 ,  is  shown  at  the  bottom  of  each 
column.  A  negative  average  indicates  an  overall  negative  impact  or  low  maturity;  an  average 
above  zero  indicates  a  positive  impact  or  more  mature  overall  assessment.  Because  this 
scale  is  very  coarse  and  the  relationships  between  the  dimension  and  quality  attribute  are 
complex,  this  overall  rating  should  be  used  only  as  a  rough  indication  of  overall  impact  or 
maturity. 


3.5  Assessment  Example 

The  example  below  displays  ratings  for  one  of  the  1 3  quality  attributes,  Security,  for  the  Web 
services  standard,  Security  Assertion  Markup  Language  (SAML),  assessed  in  terms  of  impact 
and  maturity  in  relation  to  our  notional  LTS  project.  This  particular  standard  is  maintained  by 
an  OASIS  committee.  Since  this  standard  is  directly  related  to  the  security  quality  attribute, 
the  impact  value  we  assigned  is  “Positive.”  The  development  of  Version  1.0  of  this  standard 
began  in  2001  and  was  adopted  in  November  2002.  However,  after  three  years  of  wide 
adoption,  OASIS  and  others  are  actively  working  on  Version  2.0  of  this  standard.  For  this 
reason,  we  assigned  a  maturity  rating  of  “Adolescent.” 

Impact  Maturity 

Security  Positive  Adolescent 

Standardize  passing  of  security  information  Ver.  1 .0  is  mature  but  ver.  2.0  released 

recently  (2005) 

For  each  quality  attribute,  we  applied  similar  reasoning  to  assign  one  of  the  three  ratings  for 
the  impact  and  maturity  assessments.  As  shown  in  the  appendix,  after  rating  all  of  the 
relationships  for  this  standard,  an  overall  rating  of  0.46  was  calculated  for  impact  and  0.00 
for  maturity.  Since  the  overall  impact  rating  is  a  positive  number,  it  indicates  that  SAML  has 
a  positive  impact  to  the  overall  capabilities  of  LTS.  Because  there  was  recent  release  of 
SAML,  each  maturity  relationship  was  rated  at  “Adolescent”  (sometimes  for  different 
reasons)  to  achieve  the  overall  rating  of  0.00.  This  value  indicates  that  the  LTS  stakeholders 
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should  monitor  the  project’s  security  design  decisions  along  with  the  new  SAML  changes  as 
the  new  release  becomes  part  of  the  LTS  project. 


The  appendix  contains  example  results  for  38  Web  services  standards,  assessed  for  impact 
and  maturity,  based  on  13  quality  attributes. 
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4  Conclusion 


This  technical  note  demonstrates  one  way  of  systematically  assessing  the  appropriateness  of 
using  a  popular  but  evolving  technology,  Web  services  standards.  By  focusing  on  the 
project’s  quality  attributes,  another  dimension  to  technology  assessments  can  be  added  to 
help  software  architects,  engineers,  and  project  managers  make  complex  decisions.  We  chose 
the  popular  Web  services  standards  technology  as  an  example  in  the  hope  that  the  results  of 
our  examination  will  be  useful  to  active  projects. 

Use  this  assessment  tool  and  the  associated  process  as  a  beginning  and  tailor  it  to  meet  the 
needs  of  applications  and  services  that  use  Web  services  standards.  The  goal  is  to  make 
informed  decisions  and  track  those  decisions  on  a  regular  basis.  Remember  the  ‘axe’ 
mentioned  by  Einstein;  technology  assumptions  change  frequently  so  the  decisions  based  on 
these  assumptions  need  to  be  reviewed  regularly. 
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Appendix  A  Appropriateness  Assessment  Results 


The  information  presented  in  this  appendix  was  prepared  by  the  authors  in  November  2005 
and  is  presented  as  a  baseline  analysis  of  Web  services  standards.  The  reference  project  was  a 
typical  project  using  Web  services  standards  such  as  the  LTS  project  described  in  the  report. 
The  modification  and  expansion  of  the  appropriateness  assessment  results  presented  in  this 
appendix  is  required  for  effective  use  in  your  project.  The  assessment  tool  you  use  should  be 
tailored  to  the  specific  needs  of  a  project  by 

•  selecting  which  quality  attributes  to  track  based  on  your  project’s  requirements 

•  selecting  which  standards  are  tracked  to  meet  project  requirements 

•  tracking  selected  commercial  Web  services  products  to  determine  the  appropriateness  of 
the  solution 

One  last  caution  is  that  this  technical  note  does  not  address  how  you  should  make  decisions 
such  as  gathering  the  information  for  each  comparison  or  how  to  make  system  level  decisions 
based  on  this  tool.  There  are  many  ways  to  do  this,  ranging  from  plain  old  guessing,  informal 
opinion  gathering  and  synthesis,  or  a  more  structured  approach  like  Wideband  Delphi.  The 
method  you  choose  will  vary,  depending  on  your  project’s  needs. 


How  to  Read  the  Results 

The  results  are  presented  alphabetically  according  to  the  standard’s  name.  At  the  top  of  each 
page  a  line  of  text  indicates  the  managing  organization  and  the  version  and  date  of  the 
standard’s  documentation  that  was  used  for  the  analysis.  Each  page  contains  two  data 
columns.  The  first  column  represents  the  impact  that  the  standard  has  relative  to  each 
individual  quality  attribute.  A  simple  three-level  scale  was  selected  to  indicate  a  positive, 
minimal,  or  negative  impact  in  this  relationship. 

The  standard  tends  to  support  the  quality  attribute. 

The  standard  has  little  or  no  affect  on  the  quality  attribute. 

The  standard  tends  to  degrade  the  quality  attribute. 


The  second  column  represents  the  maturity  of  the  standard  in  relation  to  each  quality 
attribute. 
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Mature 


Adolescent 


The  standard  is  widely  used  and  is  not  expected  to  change  as  related  to  the  quality 
attribute. 


The  standard  is  in  low  use  or  may  change  as  related  to  the  quality  attribute. 


The  standard  is  not  in  significant  use  or  is  likely  to  change  as  related  to  the  quality 
attribute. 


Each  page  in  this  appendix  contains  the  assessment  results  for  a  single  standard  with  regard 
to  impact  and  maturity  as  they  relate  to  each  of  the  13  quality  attributes.  Below  each  rating  is 
a  brief  comment  that  indicates  the  reason  for  the  rating. 

To  get  an  idea  of  the  overall  impact  or  maturity  for  each  standard,  a  number  between  -1  and  1 
is  shown  at  the  bottom  of  each  column.  For  each  individual  result  we  assigned  a  numeric 
value  of  1,  0,  or  -1  and  then  averaged  these  values  for  the  whole  column.  For  the  impact 
column,  the  average  is  a  rough  indication  of  how  the  standard  may  negatively  or  positively 
impact  the  system.  For  the  maturity  column,  the  average  is  a  rough  indication  of  how  mature 
the  standard  is  in  relation  to  the  system’s  quality  attributes.  Remember  that  the  results 
presented  here  were  not  derived  from  detailed  analysis  or  an  actual  project’s  architecture. 
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tVS  Standard:  Asynchronous  Service  Access  Protocol  (ASAP) 
Organization:  OASIS,  Ver:  vl.O  5/05 

Impact  Maturity 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Positive 

More  flexibility  in  integrating  services 
and  processes 


Difficult  to  audit  asynchronous  services 

Minimal 
Not  key  QA 


Positive 

Allows  for  integration  of  processes 


Positive 

Allows  for  better  interoperability  with 
longer  running  services 

Minimal 
Not  key  QA 


Minimal 


Allows  for  asynchronous  service  to  be 
integrated 


Asynchronous  services  can  negatively 
affect  performance 

Minimal 

Does  not  affect  the  reliability  of  the 
service 


Asynchronous  service  is  hard  to  predict 
as  system  grows 

Minimal 
Not  key  QA 


Difficulty  in  testing  asynchronous 
services 

Minimal 

Allows  for  monitors  and  controls  that 
may  provide  better  interactions  with 
users 


Adolescent 

Althouqh  new,  probably  won't  change  much 
for  this  QA 


Anticipate  change  for  this  QA 


Adolescent 

Althouqh  new,  probably  won't  chanqe  much 
for  this  QA 


Adolescent 

Although  new,  probably  won't  change  much 
for  this  QA 


Anticipate  change  for  this  QA 


Adolescent 

Althouqh  new,  probably  won't  chanqe  much 
for  this  QA 


Adolescent 


Althouqh  new,  probably  won't  chanqe  much 
for  this  QA 


Anticipate  change  for  this  QA 


Adolescent 

Althouqh  new,  probably  won't  chanqe  much 
for  this  QA 


Anticipate  change  for  this  QA 


Adolescent 

Althouqh  new,  probably  won't  chanqe  much 
for  this  QA 


Anticipate  change  for  this  QA 


Anticipate  change  for  this  QA 


Impact  Average:  -0.08  Maturity  Average:  -0.46 
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WS Standard:  Security  Assertion  Markup  Language  (SAML) 

Organization:  OASIS,  Ver:  v2.0  3/05 

Impact  Maturity 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Positive 

Adolescent 

Not  bound  to  specific  transportation  or 
communication  protocols 

Ver.  1.0  is  mature  but  ver.  2.0  released 
recently  (2005) 

Minimal 

Adolescent 

Not  key  QA 

Although  not  key  QA,  may  change  over  time 

Minimal 

Adolescent 

Not  key  QA 

Although  not  key  QA,  may  change  over  time 

Positive 

Adolescent 

Allows  for  additional  fields  within 
messages 

Ver.  1.0  is  mature  but  ver.  2.0  released 
recently  (2005) 

Positive 

Adolescent 

Standardizes  passing  of  security 
information 

Ver.  1.0  is  mature  but  ver.  2.0  released 
recently  (2005) 

Positive 

Adolescent 

Underlying  system  can  change  without 
need  for  changing  security 

Ver.  1.0  is  mature  but  ver.  2.0  released 
recently  (2005) 

Minimal 

Adolescent 

Not  key  QA 


More  messages  and  information  need  to 
be  passed 

Minimal 

Not  key  QA 

Positive 

Can  handle  increased  usage 


Positive 

Standardize  passing  of  security 
information 

Minimal 

Not  key  QA 

Positive 

Supports  authentication  and 
authorization 


Although  not  key  QA,  may  change  over  time 

Adolescent 

Ver.  1.0  is  mature  but  ver.  2.0  released 
recently  (2005) 

Adolescent 

Although  not  key  QA,  may  change  over  time 

Adolescent 

Ver.  1.0  is  mature  but  ver.  2.0  released 
recently  (2005) 

Adolescent 

Ver.  1.0  is  mature  but  ver.  2.0  released 
recently  (2005) 

Adolescent 

Although  not  key  QA,  may  change  over  time 

Adolescent 

Ver.  1.0  is  mature  but  ver.  2.0  released 
recently  (2005) 


Impact  Average:  0.46  Maturity  Average:  0.00 
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CMU/SEI-2006-TN-001 


tVS Standard:  Service  Provisioning  Markup  Language  (SPML) 


Organization:  OASIS,  Ver:  v2.0cd  9/05 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Impact 

Minimal 


Not  key  QA 


More  items  will  need  auditing 

Minimal 

Not  key  QA 


Positive 

Can  handle  multiple  types  of  resources 

Positive 

Provides  a  standard  for  handling 
provisioning  across  systems 

Minimal 
Not  key  QA 


Positive 


Provides  standards  for  users  and 
system  access  entitlements  which  can 
be  automated 


More  messages  to  interpret 

Minimal 

Not  key  QA 


Positive 

Allows  for  extending  the  number  of 
users  or  systems  that  need  access 
entitlements 

Positive 

Provides  standards  for  handling  user 
and  system  access  entitlements 


Difficult  in  testing  the  different  resource 
handling  scenarios 

Minimal 

Not  key  QA 


Maturity 


2nd  version  of  SPML  just  released 


2nd  version  of  SPML  just  released 

Adolescent 

Although  released  recently,  unlikely  to 
change  relative  to  this  QA 


2nd  version  of  SPML  just  released 


2nd  version  of  SPML  just  released 


Adolescent 

Although  released  recently,  unlikely  to 
change  relative  to  this  QA 

Adolescent 


Although  released  recently,  unlikely  to 
change  relative  to  this  QA 


2nd  version  of  SPML  just  released 

Adolescent 

Although  released  recently,  unlikely  to 
change  relative  to  this  QA 


2nd  version  of  SPML  just  released 


2nd  version  of  SPML  just  released 


2nd  version  of  SPML  just  released 


Adolescent 

Although  released  recently,  unlikely  to 
change  relative  to  this  QA 


Impact  Average:  0.15 


Maturity  Average:  -0 . 62 
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WS Standard:  Simple  Object  Access  Protocol  (SOAP) 
Organization:  W3C,  Ver:  vl  .2d  6/03 

Impact  Maturity 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Positive 

Adolescent 

Fields  can  be  changed.  Passes  through 
firewalls 

Anticipate  growth  related  to  this  QA 

Minimal 

Mature 

Not  key  QA 

Many  products  designed  using  SOAP 

Minimal 

Mature 

Not  key  QA 

Many  products  designed  using  SOAP 

Positive 

Adolescent 

Easily  add  fields  and  formatting 

Anticipate  growth  related  to  this  QA 

Positive 

Mature 

Designed  for  Interoperability 

Many  products  designed  using  SOAP 

Minimal 

Mature 

Not  key  QA 

Many  products  designed  using  SOAP 

Minimal 

Mature 

Not  key  QA 


Size  of  message 


Minimal 

Not  key  QA 

Positive 

Messages  can  grow  as  big  as  needed 

Minimal 

Not  key  QA 

Minimal 


Not  key  QA 


Size  of  message  and  need  for  tools 


Many  products  designed  using  SOAP 

Mature 

Many  products  designed  using  SOAP 

Mature 

Many  products  designed  using  SOAP 

Adolescent 

Anticipate  growth  related  to  this  QA 

Mature 

Many  products  designed  using  SOAP 

Mature 

Many  products  designed  using  SOAP 

Mature 

Many  products  designed  using  SOAP 


Impact  Average:  0.15 


Maturity  Average:  0.77 
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CMU/SEI-2006-TN-001 


WS Standard:  SOAP  MTOM  and/or  XOP  and/or  SWA 


Organization:  W3C,  Ver:  vO.Or  1/05 

Impact  Maturity 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Positive 

Fields  can  be  changed  in  the  message 


May  be  difficult  to  audit  optimized 
messages 

Minimal 

Not  key  QA 

Positive 

Easily  add  fields  and  formatting  to 
messages 

Positive 

Defines  rules  that  must  be  followed 

Positive 

Underlying  applications  can  change 


SWA  dying,  waiting  for 


Adolescent 

Either  method  won't  be 


SWA  dying,  waiting  for 


SWA  dying,  waiting  for 


Adolescent 


Either  method  won't  be 


Not  all  actors  in  an  SOA  may  be  using 
MTOM 

Positive 

Designed  to  optimize  transmission  of 
messages 

Minimal 

Not  key  QA 

Positive 

Messages  can  grow  but  reduces  size  of 
messages 


Optimizations  can  be  changed  by 
intermediaries 


Difficulty  in  testing  optimizations 

Minimal 

Not  key  QA 


SWA  dying,  waiting  for 


SWA  dying,  waiting  for 


Adolescent 


Either  method  won't  be 


SWA  dying,  waiting  for 


SWA  dying,  waiting  for 


SWA  dying,  waiting  for 


Adolescent 

Either  method  won't  be 


Impact  Average:  0.15 


Maturity  Average:  -0 . 69 


MTOM/XOP 

MTOM/XOP 

affected  much 

MTOM/XOP 

MTOM/XOP 

affected  much 

MTOM/XOP 

MTOM/XOP 

affected  much 

MTOM/XOP 

MTOM/XOP 

MTOM/XOP 

affected  much 


CMU/SEI-2006-TN-001 
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WS Standard:  Universal  Description  Discovery  &  Integration  (UDDI) 

Organization:  OASIS,  Ver:  v3.0  3/05 

Impact  Maturity 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Positive 

Provides  structures  for  defining  multiple 
taxonomies 

Minimal 

Not  key  QA 

Minimal 

Does  not  guarantee  the  services  will  be 
available  -  just  lists  who  is  providing 
them 

Positive 

UDDI  registries  can  be  extended 

Positive 

Part  of  the  foundational  infrastructure  for 
interoperable  services 

Minimal 

Not  key  QA 

Positive 


Allows  various  mechanisms  for  the 
publishers  to  add  entries  and  users  to 
access  them 


Not  clear  what  the  performance  of  the 
UDDI  registry  is 

Minimal 

Does  not  guarantee  reliability  of  the 
underlying  services 

Positive 

Can  handle  increasing  numbers  of 
services 

Minimal 

Needs  additional  security  mechanisms 
to  be  in  place 

Minimal 

Not  key  QA 

Positive 

Allows  searching  for  a  particular  service 


Mature 

Third  version,  should  be  stable  for  this  QA 


Adolescent 

Anticipate  improvements  for  this  QA. 

Mature 

Third  version,  should  be  stable  for  this  QA 


Mature 

Third  version,  should  be  stable  for  this  QA 

Mature 

Third  version,  should  be  stable  for  this  QA 


Mature 

Third  version,  should  be  stable  for  this  QA 

Mature 


Third  version,  should  be  stable  for  this  QA 


Adolescent 

Anticipate  improvements  for  this  QA. 


Mature 

Third  version,  should  be  stable  for  this  QA 


Adolescent 

Anticipate  improvements  for  this  QA. 


Adolescent 

Anticipate  improvements  for  this  QA. 


Adolescent 

Anticipate  improvements  for  this  QA. 

Mature 

Third  version,  should  be  stable  for  this  QA 


Impact  Average:  0.38 


Maturity  Average:  0.62 
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CMU/SEI-2006-TN-001 


WS Standard:  Web  Service  Transfer  (WS-Transfer) 

Organization:  Other,  Ver:  vO.O  9/04 

Impact  Maturity 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Positive 


Adolescent 


Allows  for  change  in  a  resource's  Although  not  widely  implemented,  standard  is 

representation  simple 


May  be  difficult  to  track  use  of  resources  Important  QA  so  it  might  change 
for  audit  purposes 


Minimal 

Positively  or  negatively  affect  the 
resources  available  to  a  service 


Adolescent 

Although  not  widely  implemented,  standard  is 
simple 


Positive 

Allows  for  change  in  a  resource's 
representation 

Minimal 


Adolescent 

Although  not  widely  implemented,  standard  is 
simple 

Adolescent 


Not  key  QA 


Although  not  widely  implemented,  standard  is 
simple 


Positive 

Allows  for  dynamic  change  of  resource 
specifications 


Adolescent 

Although  not  widely  implemented,  standard  is 
simple 


Minimal 


Adolescent 


Allows  for  deletion  and  reestablishment 
of  resources 


Removal  of  resources  can  impact 
performance 

Minimal 
Not  key  QA 


Minimal 
Not  key  QA 


Allows  for  manipulation  of  a  server's 
resources  and  change  in  resource 
specification 


May  be  difficult  to  test  the  various 
resource  scenarios 


Although  not  widely  implemented,  standard  is 
simple 


Performance  is  important  so  standard  might 
change 

Adolescent 

Although  not  widely  implemented,  standard  is 
simple 

Adolescent 

Although  not  widely  implemented,  standard  is 
simple 


Security  may  force  changes  relative  to  this  QA 


Testing  is  difficult  across  services 


Positive 

Allows  for  changes  in  resources  which 
can  have  a  positive  impact  on  user 


Adolescent 

Although  not  widely  implemented,  protocol  is 
simple 


Impact  Average:  0.00  Maturity  Average:  -0.31 
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WS Standard:  Web  Services  Atomic  Transaction  (WS-AtomicTransaction) 

Organization:  W3C,  Ver:  vl  .0  8/05 

Impact  Maturity 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Positive 

Allows  more  complex  transactions  to  be 
built 


Difficult  to  audit  potential  failures 

Minimal 

Not  key  QA 


Positive 

Allows  more  complex  transactions  to  be 
built 

Positive 

Existing  transaction  systems  can 
interoperate  across  HW  and  SW  vendors 

Minimal 

Not  key  QA 


Minimal 


Provide  consistent  failure  and  recovery 
semantics 


Does  not  guarantee  performance  of 
entire  transaction 

Positive 

With  other  standards,  guarantees 
consistent  transactions 

Minimal 

Not  key  QA 


Minimal 

Not  key  QA 


Difficulty  to  test  various  transaction 
failure  scenarios 

Positive 

With  other  standards,  guarantees 
consistent  transactions 


Adolescent 

Recently  submitted  but  all  the  major  players 
support  this  standard 


Key  QA  so  anticipate  changes 

Adolescent 

Recently  submitted  but  all  the  major  players 
support  this  standard 


Key  QA  so  anticipate  changes 


Key  QA  so  anticipate  changes 


Adolescent 

Recently  submitted  but  all  the  major  players 
support  this  standard 

Adolescent 


Recently  submitted  but  all  the  major  players 
support  this  standard 

Adolescent 

Recently  submitted  but  all  the  major  players 
support  this  standard 


Key  QA  so  anticipate  changes 


Adolescent 

Recently  submitted  but  all  the  major  players 
support  this  standard 

Adolescent 

Recently  submitted  but  all  the  major  players 
support  this  standard 


Key  QA  so  anticipate  changes 


Adolescent 

Recently  submitted  but  all  the  major  players 
support  this  standard 


Impact  Average:  0.15  Maturity  Average:  -0.38 
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CMU/SEI-2006-TN-001 


tVS Standard:  Web  Services  Business  Activity  Framework  (WS-BusinessActivity) 

Organization:  Other,  Ver:  vl.O  8/05 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Impact 


Maturity 


Positive 

Can  handle  changing  business  process 
interoperation 


More  items  need  to  be  setup  for  auditing 


3rd  version  in  a  couple  of  years.  Not 
submitted  yet. 


3rd  version  in  a  couple  of  years.  Not 
submitted  yet. 


Minimal 


Adolescent 


Not  key  QA 


Although  not  submitted,  has  strong  backing 
and  this  QA  probably  won't  change 


Positive 

Can  handle  multiple  business  processes 


3rd  version  in  a  couple  of  years.  Not 
submitted  yet. 


Positive 


Provides  standards  for  business  process  3rd  version  in  a  couple  of  years.  Not 

to  interoperate  across  different  vendor  submitted  yet. 

implementations 


Minimal 

Not  key  QA 


Adolescent 

Although  not  submitted,  has  strong  backing 
and  this  QA  probably  won't  change 


Minimal 


Adolescent 


Not  key  QA 


Although  not  submitted,  has  strong  backing 
and  this  QA  probably  won't  change 


More  coordination  of  the  business  3rd  version  in  a  couple  of  years.  Not 

processes,  storing  of  state  and  metadata  submitted  yet. 


Positive 

Defines  coordination  type  for  handling 
exceptions 

Minimal 

Not  key  QA 


Trust  boundaries  have  to  be  established 


Adolescent 

Although  not  submitted,  has  strong  backing 
and  this  QA  probably  won't  change 

Adolescent 

Although  not  submitted,  has  strong  backing 
and  this  QA  probably  won't  change 


3rd  version  in  a  couple  of  years.  Not 
submitted  yet. 


Minimal 
Not  key  QA 


Positive 

Provides  mechanisms  for  handling 
exceptions  in  business  processes 


Adolescent 

Although  not  submitted,  has  strong  backing 
and  this  QA  probably  won't  change 


3rd  version  in  a  couple  of  years.  Not 
submitted  yet. 


Impact  Average:  0.15  Maturity  Average:  -0.54 
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WS Standard:  Web  Services  Business  Process  Execution  Language  (WSBPEL) 
Organization:  OASIS,  Ver:  v2.0cd  8/05 

Impact  Maturity 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Positive 

Describes  various  mechanisms  for 
defining  business  processes 


More  items  will  need  to  be  audited  with 
little  support  provided 

Minimal 

Not  key  QA 


Positive 

New  processes  can  be  added  using  the 
standard 

Positive 

Allows  for  coordination  and  sharing  of 
information  between  web  services 

Minimal 

Not  key  QA 


Minimal 


Adolescent 

Has  wide  support  but  is  actively  being 
changed 


This  QA  is  important  and  needs  work 


Adolescent 

Has  wide  support  but  is  actively  being 
changed 

Adolescent 

Has  wide  support  but  is  actively  being 
changed 

Adolescent 

Has  wide  support  but  is  actively  being 
changed 

Adolescent 

Has  wide  support  but  is  actively  being 
changed 

Adolescent 


Not  key  QA 


More  messages  required  to  support  the 
process 

Minimal 

Does  nothing  to  ensure  the  reliability  of 
the  underlying  services 

Minimal 

Not  key  QA 


Does  not  ensure  security  level  of  the 
underlying  services 

Minimal 

Not  key  QA 


Positive 

The  level  of  automation  of  business 
processes  can  be  increased  by 
development  of  tools 


Has  wide  support  but  is  actively  being 
changed 


This  QA  is  important  and  needs  work 


Adolescent 

Has  wide  support  but  is  actively  being 
changed 

Adolescent 

Has  wide  support  but  is  actively  being 
changed 


This  QA  is  important  and  needs  work 


Adolescent 

Has  wide  support  but  is  actively  being 
changed 


This  QA  is  important  and  needs  work 


Impact  Average:  0.08  Maturity  Average:  -0.31 
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CMU/SEI-2006-TN-001 


tVS Standard:  Web  Services  Choreography  Description  Language  (WS-CDL) 
Organization:  W3C,  Ver:  vO.Owd  9/05 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Impact 


Maturity 


Positive 

An  organization  can  change  underlying 
implementation  provided  it  does  not 
change  the  Choreography 


More  items  need  to  be  audited 

Minimal 

Not  key  QA 

Positive 

An  organization  can  change  underlying 
implementation  of  its  part  of  the 
Choreography 

Positive 

Provides  for  interoperability  between 
organizations  through  standards 

Minimal 

Not  key  QA 

Minimal 


Still  in  draft,  key  QA  so  anticipate  change 


Still  in  draft,  key  QA  so  anticipate  change 


Still  in  draft  but  still  anticipate  change 


Still  in  draft,  key  QA  so  anticipate  change 


Still  in  draft,  key  QA  so  anticipate  change 


Still  in  draft  but  still  anticipate  change 


Not  key  QA 


More  message  traffic 


Minimal 

Does  not  guarantee  reliability  of 
underlying  services 

Minimal 


Not  key  QA 


More  places  where  security  can  be 
affected 

Minimal 

Not  key  QA 

Minimal 
Not  key  QA 


Still  in  draft  but  still  anticipate  change 


Still  in  draft,  key  QA  so  anticipate  change 


Still  in  draft,  key  QA  so  anticipate  change 


Still  in  draft,  key  QA  so  anticipate  change 


Still  in  draft,  key  QA  so  anticipate  change 


Still  in  draft  but  still  anticipate  change 


Still  in  draft  but  still  anticipate  change 


Impact  Average:  0.00 


Maturity  Average:  -1 .00 
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tVS  Standard:  Web  Services  Context  (WS-Context) 
Organization:  Other,  Ver:  vl.Od  10/05 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Impact 


Positive 

Allows  support  for  newly  emerging 
standards  such  as  workflow  and 
transactions 


Difficult  in  auditing  which  services  affect 
a  shared  context 

Minimal 
Not  key  QA 

Positive 

Allows  new  services  and  applications  to 
be  added 

Positive 

Allows  for  multiple  services  to  share  a 
common  context 

Minimal 
Not  key  QA 

Minimal 


Maturity 


Recent  draft,  key  QA  so  anticipate  change 


Recent  draft,  key  QA  so  anticipate  change 


Recent  draft  but  still  anticipate  change 


Recent  draft,  key  QA  so  anticipate  change 


Recent  draft,  key  QA  so  anticipate  change 


Recent  draft  but  still  anticipate  change 


Not  key  QA 


More  message  traffic  and  requires  and 
context  resource  manager 

Minimal 
Not  key  QA 

Minimal 
Not  key  QA 

Minimal 
Not  key  QA 

Minimal 
Not  key  QA 

Positive 

Allows  for  sharing  of  a  context  across 
multiple  services 


Recent  draft  but  still  anticipate  change 


Recent  draft,  key  QA  so  anticipate  change 


anticipate  change 

anticipate  change 

anticipate  change 


anticipate  change 

Recent  draft,  key  QA  so  anticipate  change 


Impact  Average:  0.15 


Maturity  Average:  -1 .00 
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CMU/SEI-2006-TN-001 


tVS Standard:  Web  Services  Coordination  (WS-Coordination) 

Organization:  Other,  Ver:  vl.O  8/05 

Impact  Maturity 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Minimal 

Not  key  QA 

Minimal 

Not  key  QA 

Minimal 

Not  key  QA 

Positive 

Allows  for  the  publication  of  coordination 
protocols  and  definition  of  extension 
elements 

Positive 

Allows  for  specifying  various 
coordination  behaviors 

Minimal 

Not  key  QA 

Positive 


Allows  for  control  of  the  coordination 
between  applications  and  services 


More  time  needed  to  establish  and  work 
through  coordination  protocols 

Positive 

Establishes  a  coordination  protocol 
between 

Positive 

Allows  for  different  coordination  protocols 


More  areas  where  security  can  be 
affected  and  needs  trusted  coordinator 


More  scenarios  to  be  tested  based  on 
the  choice  of  different  coordination 
protocols 

Positive 

Provides  for  different  coordination 
protocols  between  applications 


Adolescent 

Although  new,  this  QA  probably  won't  change 

Adolescent 

Although  new,  this  QA  probably  won't  change 

Adolescent 

Although  new,  this  QA  probably  won't  change 


Recently  changed,  products  starting  to  use 
this  standard 


Recently  changed,  products  starting  to  use 
this  standard 


Adolescent 

Although  new,  this  QA  probably  won't  change 

Adolescent 


Although  new,  this  QA  probably  won't  change 


Adolescent 

Although  new,  this  QA  probably  won't  change 


Recently  changed,  products  starting  to  use 
this  standard 


Recently  changed,  products  starting  to  use 
this  standard 


Recently  changed,  products  starting  to  use 
this  standard 


Recently  changed,  products  starting  to  use 
this  standard 


Recently  changed,  products  starting  to  use 
this  standard 


Impact  Average:  0.23  Maturity  Average:  -0.54 
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tVS Standard:  Web  Services  Coordination  Framework  (WS-CF) 

Organization:  W3C,  Ver:  vl  .0  7/03 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Impact 


Maturity 


Minimal 
Not  key  QA 


Minimal 

Not  key  QA 


Minimal 

Not  key  QA 


Positive 

Allows  for  static  and  dynamic  tailoring  to 
fit  any  context 

Positive 

Defines  a  generic  coordination  service 
that  applications  and  services  can  use 

Minimal 

Not  key  QA 


Positive 


Help  to  achieve  coordination  between 
applications  and  services 


More  message  traffic 


Positive 

Once  coordination  is  established 
provides  more  reliable  communication 

Positive 

Allows  for  different  coordination  protocols 


More  areas  where  security  could  be 
affected 

Minimal 

Not  key  QA 


Positive 

Allows  for  better  coordination  between 
services  and  applications 


Part  of  WS-CAF  but  probably  won't  change  in 
relationship  to  this  QA 


Part  of  WS-CAF  but  probably  won't  change  in 
relationship  to  this  QA 


Part  of  WS-CAF  but  probably  won't  change  in 
relationship  to  this  QA 


Part  of  WS-CAF  which  is  actively  being 
changed 


Part  of  WS-CAF  which  is  actively  being 
changed 


Part  of  WS-CAF  but  probably  won't  change  in 
relationship  to  this  QA 


Part  of  WS-CAF  which  is  actively  being 
changed 


Part  of  WS-CAF  which  is  actively  being 
changed 


Part  of  WS-CAF  which  is  actively  being 
changed 


Part  of  WS-CAF  which  is  actively  being 
changed 


Part  of  WS-CAF  which  is  actively  being 
changed 


Part  of  WS-CAF  which  is  actively  being 
changed 


Part  of  WS-CAF  which  is  actively  being 
changed 


Impact  Average:  0.31  Maturity  Average:  -1.00 
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tVS Standard:  Web  Services  Description  Language  (WSDL) 
Organization:  W3C,  Ver:  v2.0d  8/05 

Impact  Maturity 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Positive 

Service  description  in  WSDL  can  be 
adapted  to  meet  changing  needs 

Minimal 

Not  key  QA 


Minimal 

Not  key  QA 


Positive 

Service  description  in  WSDL  can  be 
extended  as  the  service  interface 
changes 

Positive 

Allows  for  the  definition  of  services 
across  multiple  environments 

Minimal 

Not  key  QA 


Positive 


A  key  piece  of  infrastructure  for 
operation  of  services 


Messages  have  to  packed  and  unpacked 

Minimal 

Not  key  QA 


Minimal 

Not  key  QA 


Minimal 
Not  key  QA 

Minimal 

Not  key  QA 


Minimal 

Not  key  QA 


Mature 

One  of  the  first  standards,  widely 
implemented 

Mature 

One  of  the  first  standards,  widely 
implemented 

Mature 

One  of  the  first  standards,  widely 
implemented 

Adolescent 

May  change  related  to  this  QA 


Adolescent 

May  change  related  to  this  QA 


Mature 

One  of  the  first  standards,  widely 
implemented 

Mature 


One  of  the  first  standards,  widely 
implemented 

Adolescent 

May  change  related  to  this  QA 

Mature 

One  of  the  first  standards,  widely 
implemented 

Mature 

One  of  the  first  standards,  widely 
implemented 

Adolescent 

May  change  related  to  this  QA 

Mature 

One  of  the  first  standards,  widely 
implemented 

Mature 

One  of  the  first  standards,  widely 
implemented 


Impact  Average:  0.23 


Maturity  Average:  0.69 
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tVS Standard:  Web  Services  Distributed  Management  (WSDM) 

Organization:  OASIS,  Ver:  vl.O  3/05 

Impact  Maturity 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Minimal 

Not  key  QA 

Positive 

Limits  the  way  that  IT  resources  can  be 
managed  and  thus  the  audit  trail 

Positive 

Provides  for  monitoring  and  enforcing  a 
service  level  agreement 

Minimal 

Not  key  QA 

Positive 

Provides  for  management  of  IT 
resources  using  web  services  and  use 
of  WS  standards 

Minimal 

Not  key  QA 

Positive 

Provides  for  monitoring  and  enforcing  a 
service  level  agreement 

Minimal 

Not  key  QA 

Positive 

Provides  for  monitoring  and  enforcing  a 
service  level  agreement 

Positive 

Can  handle  a  number  of  IT  resources 

Positive 

Limits  the  way  that  IT  resources  can  be 
managed 

Minimal 

Not  key  QA 

Minimal 

Not  key  QA 


Adolescent 

Released  recently  and  anticipate  change 


Key  QA,  anticipate  change 


Key  QA,  anticipate  change 


Adolescent 

Released  recently  and  anticipate  change 


Key  QA,  anticipate  change 


Adolescent 

Released  recently  and  anticipate  change 


Key  QA,  anticipate  change 


Adolescent 

Released  recently  (2005).  This  area  could 
change  as  needed 

Adolescent 

Released  recently  (2005).  This  area  could 
change  as  needed 


Key  QA,  anticipate  change 

Adolescent 

Released  recently  (2005).  This  area  could 
change  as  needed 


Key  QA,  anticipate  change 


Key  QA,  anticipate  change 


Impact  Average:  0.54 


Maturity  Average:  -0 . 54 
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WS Standard:  Web  Services  Dynamic  Discovery  (WS-Discovery) 
Organization:  Other,  Ver:  vO.O  4/05 

Impact  Maturity 


Adaptability 

Auditability 

Availability 


Extensibility 


Minimal 

Not  key  QA 

Minimal 

Not  key  QA 

Positive 

Dynamically  locates  service  by  type  but 
does  not  provide  information  on  the 
service's  availability 

Positive 

Provides  extensibility  for  more 
sophisticated  and  unanticipated 
scenarios 


draft 

draft 

Key  QA  and  still  in  draft 


Key  QA  and  still  in  draft 


Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 


Positive 

Allows  for  discovery  of  service  with  a 
minimum  of  networking  support 

Minimal 

Not  key  QA 

Minimal 


Key  QA  and  still  in  draft 


Not  key  QA  but  still  in  draft 


Not  key  QA 


Not  clear  how  long  it  takes  to 
dynamically  discover  services 

Minimal 

Not  key  QA 

Positive 

Allows  for  scaling  to  a  large  number  of 
endpoints 

Minimal 

Not  key  QA:  needs  other  standards 


Not  key  QA  but  still  in  draft 


Key  QA  and  still  in  draft 


Not  key  QA  but  still  in  draft 


Testability 


Usability 


Difficult  to  test  dynamic  discovery 
situations 

Minimal 

Not  key  QA 


Difficult  QA  and  still  in  draft 


Not  key  QA  but  still  in  draft 


Impact  Average:  0.15 


Maturity  Average:  -1 .00 
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tVS Standard:  Web  Services  Enumeration  (WS-Enumeration) 

Organization:  Other,  Ver:  vO.O  9/04 

Impact  Maturity 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 


Usability 


Adolescent 

Not  implemented  widely  but  unlike  to  change 
relative  to  this  QA 


Difficult  to  audit  how  large  data  sets  are  Year  old  and  not  implemented  widely 
handled 


Minimal 
Not  key  QA 


Minimal 
Not  key  QA 


Positive 

Allows  for  more  information  to  be 
passed  in  a  standard  way 

Positive 

Allows  for  better  management  of  large 
shared  data  sets 


Adolescent 

Not  implemented  widely  but  unlike  to  change 
relative  to  this  QA 


Year  old  and  not  implemented  widely 


Year  old  and  not  implemented  widely 


Minimal 

Not  key  QA 


Minimal 


Adolescent 

Not  implemented  widely  but  unlike  to  change 
relative  to  this  QA 

Adolescent 


Not  key  QA 


Minimal 

Not  key  QA 

Minimal 

Not  key  QA 


Positive 

Allows  for  handling  larger  data  sets 


More  places  for  security  to  be  impacted 


Difficult  to  test  different  enumerations 
and  to  find  one  that  works  well 

Positive 

Better  handling  of  data  sets 


Not  implemented  widely  but  unlike  to  change 
relative  to  this  QA 


Always  looking  for  performance  improvements 

Adolescent 

Not  implemented  widely  but  unlike  to  change 
relative  to  this  QA 


Year  old  and  not  implemented  widely 


Year  old  and  not  implemented  widely 


Year  old  and  not  implemented  widely 


Year  old  and  not  implemented  widely 


Impact  Average:  0.08 


Maturity  Average:  -0 . 62 
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tVS Standard:  Web  Services  Eventing  (WS-Eventing) 

Organization:  Other,  Ver:  vO.O  9/04 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Impact 


Positive 

Enables  change  in  underlying 
mechanisms 


More  items  that  may  need  to  be  audited 


Does  nothing  to  guarantee  underlying 
events 

Positive 

Allows  for  more  sophisticated  and 
unanticipated  subscription  scenarios 

Positive 

Does  not  rely  on  a  particular  mechanism 
/  defines  a  standard  for  notification 

Minimal 

Not  key  QA 


Positive 


Allows  subscriber  define  the  way 
messages  are  delivered 


More  message  between  providers  and 
users 


Does  nothing  to  guarantee  reliability  of 
underlying  events 

Positive 

Standard  way  to  specify  subscription 
and  notification 


Need  to  leverage  other  specifications 


More 

specifications/scenarios/mechanisms 
that  need  to  be  tested 

Positive 

Standard  way  to  specify  subscription 
and  notification 


Maturity 


Battling  with  WS-Notification  and  last  version 
is  2004 


Battling  with  WS-Notification  and  last  version 
is  2004 


Battling  with  WS-Notification  and  last  version 
is  2004 


Battling  with  WS-Notification  and  last  version 
is  2004 


Battling  with  WS-Notification  and  last  version 
is  2004 


Battling  with  WS-Notification  and  last  version 
is  2004 


Battling  with  WS-Notification  and  last  version 
is  2004 


Battling  with  WS-Notification  and  last  version 
is  2004 


Battling  with  WS-Notification  and  last  version 
is  2004 


Battling  with  WS-Notification  and  last  version 
is  2004 


Battling  with  WS-Notification  and  last  version 
is  2004 


Battling  with  WS-Notification  and  last  version 
is  2004 


Battling  with  WS-Notification  and  last  version 
is  2004 


Impact  Average:  0.00 


Maturity  Average:  -1 .00 
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tVS Standard:  Web  Services  Federation  Language  (WS-Federation) 

Organization:  Other,  Ver:  vl.O  7/03 

Impact  Maturity 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Positive 

Service  Users  are  required  to  know 
more  about  what  security  mechanisms 
providers  are  using. 


More  information  and  scenarios  to  audit 


Minimal 

Not  key  QA 


Minimal 
Not  key  QA 


Positive 

Allows  for  multiple  system  to  interact 


Minimal 

Not  key  QA 


Minimal 


Not  key  QA 


More  messages  between  users  and 
providers 

Minimal 

Not  key  QA 


Positive 

Can  handle  multiple  systems 


Positive 

Allows  for  a  variety  of  security 
mechanisms  to  be  used 


Difficult  to  test  scenarios  for  how 
systems  will  be  federated 

Minimal 

Not  key  QA 


Not  implemented  widely  and  it  interacts  with 
3  other  standards 


Not  implemented  widely  and  it  interacts  with 
3  other  standards 


Adolescent 

Not  implemented  widely  but  unlikely  to  be 
modified  relative  to  this  QA 

Adolescent 

Not  implemented  widely  but  unlikely  to  be 
modified  relative  to  this  QA 


Not  implemented  widely  and  it  interacts  with 
3  other  standards 


Adolescent 

Not  implemented  widely  but  unlikely  to  be 
modified  relative  to  this  QA 

Adolescent 


Not  implemented  widely  but  unlikely  to  be 
modified  relative  to  this  QA 


Not  implemented  widely  and  it  interacts  with 
3  other  standards 

Adolescent 

Not  implemented  widely  but  unlikely  to  be 
modified  relative  to  this  QA 


Not  implemented  widely  and  it  interacts  with 
3  other  standards 


Not  implemented  widely  and  it  interacts  with 
3  other  standards 


Not  implemented  widely  and  it  interacts  with 
3  other  standards 

Adolescent 

Not  implemented  widely  but  unlikely  to  be 
modified  relative  to  this  QA 


Impact  Average:  0.08 


Maturity  Average:  -0 . 54 
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tVS  Standard:  Web  Services  for  Remote  Portlets  (WSRP) 
Organization:  OASIS,  Ver:  v2.0d  10/05 

Impact  Maturity 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Minimal 

Not  key  QA 

Minimal 

Not  key  QA 

Minimal 

Not  key  QA 

Positive 

New  interfaces  and  portlets  can  be 
added 

Positive 

Provides  well-defined  interfaces  for 
pluggable  presentation-oriented  web 
services 

Positive 

Built  using  existing  standards 

Positive 


Allows  integration  of  new  portlets  in  a 
portal  without  the  need  for  custom 
coding  or  deployment  activities 


Allows  end-user  to  interact  directly  with 
service 

Minimal 

Not  key  QA 

Minimal 


Not  key  QA 


Allows  more  interfaces  and  services  to 
be  used  with  more  areas  for  security  to 
be  affected 

Minimal 

Not  key  QA 

Positive 

Directly  targeted  to  end-user 
presentation  web  services 


Adolescent 

Although  in  draft,  this  QA  not  likely  to  change 
Adolescent 

Although  in  draft,  this  QA  not  likely  to  change 

Adolescent 

Although  in  draft,  this  QA  not  likely  to  change 


Key  QA,  anticipate  change 


Key  QA,  anticipate  change 


Adolescent 

Although  in  draft,  this  QA  not  likely  to  change 


Key  QA,  anticipate  change 


Key  QA,  anticipate  change 


Adolescent 

Although  in  draft,  this  QA  not  likely  to  change 

Adolescent 

Although  in  draft,  this  QA  not  likely  to  change 


Key  QA,  anticipate  change 


Adolescent 

Although  in  draft,  this  QA  not  likely  to  change 

Adolescent 

Although  in  draft,  this  QA  not  likely  to  change 


Impact  Average:  0.23 


Maturity  Average:  -0.38 
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tVS Standard:  Web  Services  Inspection  Language  (WS-lnspection) 
Organization:  Other,  Ver:  vl.O  11/01 

Impact  Maturity 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Positive 

Can  allow  the  users  to  pick  and  choose 
which  descriptions  they  want  to  use 

Minimal 

Not  key  QA 

Minimal 

Not  key  QA 

Positive 

Can  add  new  repositories  of 
descriptions  as  they  become  available 

Positive 

Provides  mechanisms  for  referencing 
and  utilizing  existing  repositories  of 
service  descriptions 

Minimal 

Not  key  QA 

Minimal 


Not  key  QA 

Minimal 
Not  key  QA 

Minimal 

Not  key  QA 

Minimal 
Not  key  QA 

Minimal 
Not  key  QA 

Minimal 
Not  key  QA 

Minimal 

Not  key  QA 


Key  QA  but  no  activity  since  2001 


Adolescent 

Not  key  QA  and  also  no  activity  since  2001 

Adolescent 

Not  key  QA  and  also  no  activity  since  2001 


Key  QA  but  no  activity  since  2001 


Key  QA  but  no  activity  since  2001 


Adolescent 

Not  key  QA  and  also  no  activity  since  2001 

Adolescent 


Not  key  QA  and  also  no  activity  since  2001 

Adolescent 

Not  key  QA  and  also  no  activity  since  2001 

Adolescent 

Not  key  QA  and  also  no  activity  since  2001 


Key  QA  but  no  activity  since  2001 

Adolescent 

Not  key  QA  and  also  no  activity  since  2001 

Adolescent 

Not  key  QA  and  also  no  activity  since  2001 

Adolescent 

Not  key  QA  and  also  no  activity  since  2001 


Impact  Average:  0.23 


Maturity  Average:  -0.31 
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tVS  Standard:  Web  Services  Metadata  Exchange  (WS-MetadataExchange) 
Organization:  Other,  Ver:  vO.O  09/04 

Impact  Maturity 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Minimal 
Not  key  QA 


Minimal 
Not  key  QA 

Minimal 
Not  key  QA 


Positive 

Allows  for  different  types  of  metadata 
about  a  service  to  be  retrieved 

Positive 

Allow  for  exchange  of  metadata  between 
services  and  various  users 

Minimal 

Not  key  QA 

Minimal 


Not  key  QA 

Minimal 
Not  key  QA 

Minimal 
Not  key  QA 


Minimal 

Not  key  QA 

Minimal 

May  have  security  implications  if  all 
metadata  about  a  service  can  be 
retrieved 

Minimal 

Not  key  QA 

Minimal 
Not  key  QA 


Adolescent 

Unlikely  to  change  relative  to  this  QA  but  still 
not  clearly  specified 


Not  key  QA,  not  clearly  specified 

Adolescent 

Unlikely  to  change  relative  to  this  QA  but  still 
not  clearly  specified 


Key  QA,  spec  not  submitted  yet 


Key  QA,  spec  not  submitted  yet 


Not  key  QA,  not  clearly  specified 


Not  key  QA,  not  clearly  specified 


Not  key  QA,  not  clearly  specified 

Adolescent 

Unlikely  to  change  relative  to  this  QA  but  still 
not  clearly  specified 


Not  key  QA,  not  clearly  specified 


Not  key  QA,  not  clearly  specified 


Not  key  QA,  not  clearly  specified 

Adolescent 

Unlikely  to  change  relative  to  this  QA  but  still 
not  clearly  specified 


Impact  Average:  0.15 


Maturity  Average:  -0 . 69 
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tVS  Standard:  Web  Services  Notification  (WSN) 
Organization:  OASIS,  Ver:  v1.3d  7/05 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Impact 

Minimal 

Not  key  QA 


Another  piece  to  audit 


Minimal 

Not  key  QA 


Minimal 
Not  key  QA 


Positive 

Standardizes  how  notifications  are 
handled 

Minimal 

Not  key  QA 


Positive 


Maturity 


Battling  with  WS-Eventing  and  last  version  is 
2004 


Battling  with  WS-Eventing  and  last  version  is 
2004 


Battling  with  WS-Eventing  and  last  version  is 
2004 


Battling  with  WS-Eventing  and  last  version  is 
2004 


Battling  with  WS-Eventing  and  last  version  is 
2004 


Battling  with  WS-Eventing  and  last  version  is 
2004 


Allows  for  standard  way  for  notifying 
interested  parties  on  topics 


Increase  in  number  of  messages 


Lots  of  actors  in  an  SOA  have  to  be 
using  the  standard 

Positive 

Use  standards  across  an  SOA 


More  places  for  security  to  be  impacted 


Adds  additional  items  that  need  to  be 
tested 

Positive 

Standardizes  notification  on  topics 


Battling  with  WS-Eventing  and  last  version  is 
2004 


Battling  with  WS-Eventing  and  last  version  is 
2004 


Battling  with  WS-Eventing  and  last  version  is 
2004 


Battling  with  WS-Eventing  and  last  version  is 
2004 


Battling  with  WS-Eventing  and  last  version  is 
2004 


Battling  with  WS-Eventing  and  last  version  is 
2004 


Battling  with  WS-Eventing  and  last  version  is 
2004 


Impact  Average:  -0.08  Maturity  Average:  -1.00 
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tVS Standard:  Web  Services  Policy  Attachment  (WS-PolicyAttachment) 

Organization:  Other,  Ver:  vO.O  9/04 

Impact  Maturity 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Positive 

The  attachment  of  policies  to  service 
can  be  altered 

Minimal 
Not  key  QA 


Minimal 

Not  key  QA 

Positive 

Allows  for  multiple  policies  to  be 
attached  to  a  service 

Positive 

Defines  mechanisms  for  associating 
policies  with  services 

Positive 

The  set  of  policies  attached  to  a  service 
can  be  changed 

Minimal 


Not  key  QA 


May  have  a  performance  hit  if  multiple 
policies  are  attached  to  a  service  and 
the  effective  policy  needs  to  be  identified 

Minimal 

Not  key  QA 

Minimal 

Not  key  QA 

Positive 

Allows  for  a  security  policy  to  be 
associated  with  a  service 


Difficult  to  test  all  of  the  policies 
attached  to  a  service  and  how  they  are 
handled 

Minimal 

Not  key  QA 


Key  QA  but  not  submitted  yet 


Not  key  QA  but  likely  to  change  to  improve 
auditing 

Adolescent 

Not  key  QA,  probably  won't  change 


Key  QA  but  not  submitted  yet 


Key  QA  but  not  submitted  yet 


Key  QA  but  not  submitted  yet 


Adolescent 


Not  key  QA,  probably  won't  change 

Adolescent 

Not  key  QA,  probably  won't  change 


Adolescent 

Not  key  QA,  probably  won't  change 

Adolescent 

Not  key  QA,  probably  won't  change 

Adolescent 

Base  standard,  probably  won't  change 


Not  key  QA  but  likely  to  change  to  improve 
testing 


Adolescent 

Not  key  QA,  probably  won't  change 


Impact  Average:  0.23 


Maturity  Average:  -0.46 
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tVS Standard:  Web  Services  Policy  Framework  (WS-Policy) 

Organization:  Other,  Ver:  vO.O  9/04 

Impact  Maturity 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Positive 

Policies  can  be  adapted  based  on 
changes  in  the  services 

Minimal 

Not  key  QA 


Minimal 

Not  key  QA 


Key  QA  but  not  submitted  yet 


Adolescent 

Although  not  submitted,  unlikely  to  change 
relative  to  this  QA 

Adolescent 

Although  not  submitted,  unlikely  to  change 
relative  to  this  QA 


Positive 

Policies  can  extended  when  new 
capabilities  are  added 

Positive 

Provides  for  a  standard  way  of  defining 
capabilities,  requirements  and 
characteristics  of  services 

Positive 

The  underlying  policies  can  be  changed 
easily 

Positive 


Adolescent 

Although  not  submitted  yet,  designed  to  be 
extensible 


Allows  for  the  description  of  capabilities, 
requirements  and  characteristics  of 
services 


Possibly  more  message  traffic  between 
a  service  provider  and  user 


Can  be  used  to  define  security  policy 
and  dynamically  interpreted 


Testing  that  a  service  meets  stated 
policies  may  be  difficult 

Minimal 

Not  key  QA 


Key  QA  but  not  submitted  yet 


Adolescent 

Unlikely  to  change  to  improve  performance 


Adolescent 

Although  not  submitted,  unlikely  to  change 
relative  to  this  QA 

Adolescent 

Although  not  submitted,  unlikely  to  change 
relative  to  this  QA 

Adolescent 

Base  standard  that  seems  extensible  enough 


Not  key  QA  but  improvement  needed  for 
testing 

Adolescent 

Although  not  submitted,  unlikely  to  change 
relative  to  this  QA 


Impact  Average:  0.31  Maturity  Average:  -0.38 
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tVS Standard:  Web  Services  Reliable  Messaging  (WS-Reliability) 
Organization:  OASIS,  Ver:  vl.1  11/04 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Impact 


Positive 

Different  network  transportation 
technologies  can  be  used 

Minimal 
Not  key  QA 


Positive 

Overcomes  network  and  software 
component  failures 

Minimal 

Not  key  QA 


Minimal 
Not  key  QA 


Minimal 
Not  key  QA 


Positive 


Maturity 


Battling  with  WS-ReliableMessaging,  major 
companies  on  both  sides 


Battling  with  WS-ReliableMessaging,  major 
companies  on  both  sides 


Battling  with  WS-ReliableMessaging,  major 
companies  on  both  sides 


Battling  with  WS-ReliableMessaging,  major 
companies  on  both  sides 


Battling  with  WS-ReliableMessaging,  major 
companies  on  both  sides 


Battling  with  WS-ReliableMessaging,  major 
companies  on  both  sides 


Overcomes  problems  with  failures 


Increases  size  of  messages 


Positive 

Key  QA  -  provides  reliable  messaging 


Minimal 

Not  key  QA 


Minimal 

Acknowledgement  of  message  reaching 
destination 


Difficulties  in  testing  failure  scenarios 


Positive 

Overcomes  problems  with  failures 


Battling  with  WS-ReliableMessaging,  major 
companies  on  both  sides 


Battling  with  WS-ReliableMessaging,  major 
companies  on  both  sides 


Battling  with  WS-ReliableMessaging,  major 
companies  on  both  sides 


Battling  with  WS-ReliableMessaging,  major 
companies  on  both  sides 


Battling  with  WS-ReliableMessaging,  major 
companies  on  both  sides 


Battling  with  WS-ReliableMessaging,  major 
companies  on  both  sides 


Battling  with  WS-ReliableMessaging,  major 
companies  on  both  sides 


Impact  Average:  0.23  Maturity  Average:  -1.00 
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WS Standard:  Web  Services  Reliable  Messaging  Protocol  (WS-ReliableMessaging) 

Organization:  OASIS,  Ver:  vl.O  2/05 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Impact 


Maturity 


Positive 

Different  network  transport  technologies 
can  be  used 


Battling  with  WS-Reliability,  major  companies 
on  both  sides 


Minimal 

Not  key  QA 


Battling  with  WS-Reliability,  major  companies 
on  both  sides 


Positive 

Overcomes  problems  with  failures 


Battling  with  WS-Reliability,  major  companies 
on  both  sides 


Minimal 

Not  key  QA 


Minimal 

Not  key  QA 


Battling  with  WS-Reliability,  major  companies 
on  both  sides 


Battling  with  WS-Reliability,  major  companies 
on  both  sides 


Minimal 

Not  key  QA 


Battling  with  WS-Reliability,  major  companies 
on  both  sides 


Positive 


Overcomes  problems  with  failures 


Increases  size  of  messages 


Positive 

Overcomes  failures  in  networks  and 
software  components 

Minimal 

Not  key  QA 


Minimal 

Not  key  QA 


Difficulties  in  testing  failure  scenarios 


Positive 

Overcomes  problems  with  failures 


Battling  with  WS-Reliability,  major  companies 
on  both  sides 


Battling  with  WS-Reliability,  major  companies 
on  both  sides 


Battling  with  WS-Reliability,  major  companies 
on  both  sides 


Battling  with  WS-Reliability,  major  companies 
on  both  sides 


Battling  with  WS-Reliability,  major  companies 
on  both  sides 


Battling  with  WS-Reliability,  major  companies 
on  both  sides 


Battling  with  WS-Reliability,  major  companies 
on  both  sides 


Impact  Average:  0.23  Maturity  Average:  -1.00 
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tVS Standard:  Web  Services  Resource  (WS-Resource) 
Organization:  OASIS,  Ver:  v1.2d  10/05 

Impact  Maturity 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Minimal 

Not  key  QA 


Minimal 

Not  key  QA 


Minimal 

Does  not  guarantee  availability  of 
resource 

Positive 

Extensions  can  be  made  to  the  existing 
resource  handling 

Positive 

Provides  a  standard  mechanism  for 
describing  resources  across 
organizations 

Minimal 

Not  key  QA 


Positive 


Allows  for  aggregation  of  resource  and 
service  information  into  dictionaries 
which  can  be  published 

Minimal 

Not  key  QA 

Minimal 

Not  key  QA 

Positive 

New  resources  can  be  added 

Minimal 

Not  key  QA 


Minimal 

Not  key  QA 

Positive 

Provides  for  standardized  forms  of 
messages  for  interacting  with  a  resource 


Although  not  key  QA,  standard  is  in  an  active 
working  group 


Although  not  key  QA,  standard  is  in  an  active 
working  group 

Adolescent 

Not  key  QA  and  is  not  likely  to  change 


Key  QA  and  still  in  active  working  group 


Key  QA  and  still  in  active  working  group 


Although  not  key  QA,  standard  is  in  an  active 
working  group 


Key  QA  and  still  in  active  working  group 


Adolescent 

Not  key  QA  and  is  not  likely  to  change 

Adolescent 

Not  key  QA  and  is  not  likely  to  change 


Key  QA  and  still  in  active  working  group 


Although  not  key  QA,  standard  is  in  an  active 
working  group 

Adolescent 

Not  key  QA  and  is  not  likely  to  change 


Key  QA  and  still  in  active  working  group 


Impact  Average:  0.38  Maturity  Average:  -0.69 
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WS Standard:  Web  Services  Secure  Conversation  Language  (WS- 
SecureConversation) 

Organization:  Other,  Ver:  vO.O  2/05 

Impact  Maturity 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Minimal 
Not  key  QA 


Minimal 
Not  key  QA 

Minimal 
Not  key  QA 

Minimal 

Not  key  QA 


Positive 

Defines  standard  for  handling  security 
across  systems 

Minimal 

Not  key  QA 

Minimal 


Not  key  QA 

Minimal 

Not  key  QA 

Minimal 

Not  key  QA 


Minimal 

Not  key  QA 


Positive 

Establishes  context,  sharing  and 
session  keys 


More  scenarios  for  testing 

Minimal 

Not  key  QA 


Adolescent 

Not  submitted  yet  but  unlikely  to  be  modified 
relative  to  this  QA 


4  years  and  not  submitted  yet 


4  years  and  not  submitted  yet 

Adolescent 

Not  submitted  yet  but  unlikely  to  be  modified 
relative  to  this  QA 


4  years  and  not  submitted  yet 


4  years  and  not  submitted  yet 


4  years  and  not  submitted  yet 


4  years  and  not  submitted  yet 

Adolescent 

Not  submitted  yet  but  unlikely  to  be  modified 
relative  to  this  QA 

Adolescent 

Not  submitted  yet  but  unlikely  to  be  modified 
relative  to  this  QA 


4  years  and  not  submitted  yet 


4  years  and  not  submitted  yet 


4  years  and  not  submitted  yet 


Impact  Average:  0.08 


Maturity  Average:  -0 . 69 
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tVS Standard:  Web  Services  Security  (WS-Security) 

Organization:  OASIS,  Ver:  1.0  3/04 

Impact  Maturity 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Minimal 


Not  key  QA 


More  information  needs  to  be  audited 


Minimal 

Establish  secure  communication  but  no 
guarantee  of  service  failure 

Positive 

Security  messages  are  extensible  and 
additional  fields  can  be  added 

Positive 

Allows  for  loose  or  tightly  coupled 
systems,  requires  policies  to  be  well 
defined 

Positive 

Underlying  service  can  change  without 
change  in  message 

Minimal 


Not  key  QA 


Additional  message  and  increased  size 


Positive 

Establish  secure  communication 


Minimal 

Not  key  QA 

Positive 

Built  for  confidential  message 
transmission 


More  messages  and  scenarios  to  be 
tested 


Minimal 

Not  key  QA 


Mature 

Widely  implemented 

Adolescent 

As  auditing  is  addressed  better,  changes 
might  happen 

Mature 

Widely  implemented 


Mature 

Widely  implemented 


Mature 

Widely  implemented 


Mature 

Widely  implemented 


Mature 


Widely  implemented 

Adolescent 

Always  looking  for  ways  to  improve 
performance 

Mature 

Widely  implemented 

Mature 

Widely  implemented 

Adolescent 

Although  widely  implemented,  this  key  QA 
may  be  affected 

Adolescent 

As  testing  is  addressed  better,  changes 
might  happen 

Mature 

Widely  implemented 


Impact  Average:  0.15 


Maturity  Average:  0.69 
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tVS Standard:  Web  Services  Security  Policy  Language  (WS-SecurityPolicy) 

Organization:  Other,  Ver:  vl.1  7/05 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Impact 


Need  to  rewrite  engine  to  support 
additional  specification  mechanisms 


Difficulty  in  auditing  multiple  policies  and 
underlying  security 

Minimal 

Not  key  QA 


Positive 

Can  be  extended  to  handle  additional 
security  specifications 

Positive 

Generic  to  a  security  specification  and 
not  confined  to  use  WS-Security 


Have  to  be  re-implemented  for  each 
security  spec  to  verify  policy 

Minimal 


Not  key  QA 


More  messages  and  increase  in 
message  size 

Minimal 
Not  key  QA 


Positive 

Can  handle  multiple  specification 
mechanisms 

Positive 

Build  specifically  for  managing  security 


Difficult  to  test  underlying  security 
specifications  and  policies 

Minimal 

Not  key  QA 


Maturity 


Recently  released,  relies  on  other  immature 
standards 


Recently  released,  relies  on  other  immature 
standards 

Adolescent 

Although  recently  released,  unlikely  to 
change  relative  to  this  QA 


Recently  released,  relies  on  other  immature 
standards 


Recently  released,  relies  on  other  immature 
standards 


Recently  released,  relies  on  other  immature 
standards 

Adolescent 


Although  recently  released,  unlikely  to 
change  relative  to  this  QA 


Although  recently  released,  performance 
improvements  are  unlikely 

Adolescent 

Although  recently  released,  unlikely  to 
change  relative  to  this  QA 


Recently  released,  relies  on  other  immature 
standards 


Recently  released,  relies  on  other  immature 
standards 


Recently  released,  relies  on  other  immature 
standards 

Adolescent 

Although  recently  released,  unlikely  to 
change  relative  to  this  QA 


Impact  Average:  -0.08 


Maturity  Average:  -0 . 69 
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tVS  Standard:  Web  Services  Transaction  Management  (WS-TXM) 

Organization:  OASIS,  Ver:  vl.O  7/03 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Impact 


Maturity 


Minimal 

Not  key  QA 


Minimal 

Not  key  QA 


Minimal 

Not  key  QA 


Positive 

Allows  for  different  transaction  models 


Positive 

Defines  mechanisms  for  structuring  long 
running  transactions  across  applications 
and  services 


Although  released  in  2003,  it  has 
incorporated  into  products  yet. 


Although  released  in  2003,  it  has 
incorporated  into  products  yet. 


Although  released  in  2003,  it  has 
incorporated  into  products  yet. 


Although  released  in  2003,  it  has 
incorporated  into  products  yet. 


Although  released  in  2003,  it  has 
incorporated  into  products  yet. 


Minimal 

Not  key  QA 


Positive 


Although  released  in  2003,  it  has 
incorporated  into  products  yet. 


Allows  for  long-running  transactions  to 
be  handled 


More  messages  and  coordination 
needed 

Positive 

Mechanisms  for  handling  the  reliable 
execution  of  transactions 

Minimal 

Not  key  QA 


More  places  where  security  could  be 
impacted 

Minimal 

Not  key  QA 


Minimal 

Not  key  QA 


Although  released  in  2003,  it  has 
incorporated  into  products  yet. 


Although  released  in  2003,  it  has 
incorporated  into  products  yet. 


Although  released  in  2003,  it  has 
incorporated  into  products  yet. 


Although  released  in  2003,  it  has 
incorporated  into  products  yet. 


Although  released  in  2003,  it  has 
incorporated  into  products  yet. 


Although  released  in  2003,  it  has 
incorporated  into  products  yet. 


Although  released  in  2003,  it  has 
incorporated  into  products  yet. 


Impact  Average:  0.15 


Maturity  Average:  -1 .00 


not  been 


not  been 


not  been 


not  been 


not  been 


not  been 


not  been 


not  been 


not  been 


not  been 


not  been 


not  been 


not  been 
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WS Standard:  Web  Services  Trust  Language  (WS-Trust) 

Organization:  Other,  Ver:  vO.O  2/05 

Impact  Maturity 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Minimal 
Not  key  QA 


More  specifications  and  scenarios  to  be 
audited 

Positive 

Ability  to  establish  more  trustworthy 
services 

Minimal 
Not  key  QA 


Positive 

Defines  standards  for  handling  secure 
communications 

Minimal 
Not  key  QA 


Minimal 


Not  key  QA 


More  messages  may  need  to  be 
transferred 

Minimal 
Not  key  QA 


Minimal 
Not  key  QA 

Positive 

Extends  WS-Security  for  secure 
communication 


More  specifications  and  scenarios  to  be 
tested 


Minimal 

Not  key  QA 


Adolescent 


Not  key  QA,  unlikely  to  change  relative  to  this 
QA 


Key  security  standard,  recently  updated 
(2005) 


Key  security  standard,  recently  updated 
(2005) 

Adolescent 


Not  key  QA,  unlikely  to  change  relative  to  this 
QA 


Key  security  standard,  recently  updated 
(2005) 

Adolescent 


Not  key  QA,  unlikely  to  change  relative  to  this 
QA 


Adolescent 


Not  key  QA,  unlikely  to  change  relative  to  this 
QA 


Performance  may  need  to  be  improved 


Adolescent 


Not  key  QA,  unlikely  to  change  relative  to  this 
QA 


Scalability  may  need  to  be  improved 


Key  security  standard,  recently  updated 
(2005) 


Key  security  standard,  recently  updated 
(2005) 


Adolescent 


Not  key  QA,  unlikely  to  change  relative  to  this 
QA 


Impact  Average:  0.00 


Maturity  Average:  -0 . 54 
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tVS Standard:  WS-Addressing  or  WS-MessageDelivery 

Organization:  W3C,  Ver:  vO.Od  8/04 

Impact  Maturity 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 


Reliability 

Scalability 

Security 

Testability 

Usability 


Positive 

Addressing  and  Message  delivery 
options  can  be  changed 

Minimal 

Not  key  QA 


Positive 

Improves  message  transmission 

Positive 

Easily  to  add  fields  and  formatting  to 
underlying  SOAP  message 

Positive 

A  standard  way  of  identifying  endpoints 

Minimal 

Not  key  QA 


Positive 


Improves  reliability  of  message 
transmissions 


Adds  additional  information  in  messages 
making  them  larger 

Positive 

Improves  reliability  of  message 
transmission 

Positive 

Improves  message  transmission 

Positive 

Secures  end-to-end  endpoints  in 
messages 

Minimal 

Not  key  QA:  but  endpoint  addressing 
improved 

Minimal 

Not  key  QA 


Battle  between  these  2  standards 


Adolescent 


Not  key  so  neither  standard  will  change  for 
this  QA 


Battle  between  these  2  standards 


Battle  between  these  2  standards 


Battle  between  these  2  standards 


Adolescent 

Not  key  so  neither  standard  will  change  for 
this  QA 


Battle  between  these  2  standards 


Battle  between  these  2  standards 


Battle  between  these  2  standards 


Battle  between  these  2  standards 


Battle  between  these  2  standards 


Battle  between  these  2  standards 


Adolescent 

Not  key  so  neither  standard  will  change  for 
this  QA 


Impact  Average:  0.54 


Maturity  Average:  -0 . 77 
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WS Standard:  XML-Encryption 

Organization:  W3C,  Ver:  rec  3/02 
Impact 


Adaptability 


Minimal 
Not  key  QA 


Auditability 


Availability 


More  information  needs  auditing  but 
information  is  encrypted 

Minimal 

Not  key  QA 


Extensibility 


Minimal 

Not  key  QA 


Interoperability 


Minimal 

Not  key  QA 


Modifiability 


Minimal 

Not  key  QA 


Operability  and 
Deployability 


Minimal 


Not  key  QA 


Performance 


Reliability 


Scalability 


Security 


Encryption  and  Decryption  needed 
which  requires  extra  time  to  process 
messages 


Encryption  of  messages 


Testability 


More  scenarios  to  test 


Usability 

Encryption  may  cause  delays  in  user 
responses 


Maturity 


Adolescent 

Older  standard,  not  supported  widely  in 
commercial  products 


May  be  impacted  by  future  protocols  for 
auditing 

Adolescent 

Older  standard,  not  supported  widely  in 
commercial  products 

Adolescent 

Older  standard,  not  supported  widely  in 
commercial  products 

Adolescent 

Older  standard,  not  supported  widely  in 
commercial  products 

Adolescent 

Older  standard,  not  supported  widely  in 
commercial  products 

Adolescent 


Older  standard,  not  supported  widely  in 
commercial  products 


Always  looking  for  improvements  in 
performance 


Adolescent 

Older  standard,  not  supported  widely  in 
commercial  products 

Adolescent 

Older  standard,  not  supported  widely  in 
commercial  products 


May  be  impacted  as  new  security  features 
appear 


May  be  impacted  as  new  features  need  to  be 
tested 

Adolescent 

Older  standard,  not  supported  widely  in 
commercial  products 


Impact  Average:  -0.23  Maturity  Average:  -0.31 
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tvs  Standard:  XML-Signature 

Organization:  W3C,  Ver:  rec  2/02 

Impact  Maturity 


Adaptability 

Auditability 

Availability 

Extensibility 

Interoperability 

Modifiability 

Operability  and 
Deployability 

Performance 

Reliability 

Scalability 

Security 

Testability 

Usability 


Minimal 

Not  key  QA 


More  information  and  scenarios  need  to 
be  audited 

Minimal 
Not  key  QA 


Minimal 

Not  key  QA 


Positive 

Once  keys  are  established  XML 
documents  can  be  exchanged  between 
systems 

Minimal 

Not  key  QA 


Minimal 


Not  key  QA:  requires  keys  to  be 
allocated  and  managed 

Minimal 

Not  key  QA 


Positive 

Guarantee  only  user  with  key  can 
access  message  content 

Minimal 

Not  key  QA 


Positive 

Associates  a  key  with  data  passed  in  a 
message,  needs  additional  standards 


Difficulty  testing  without  the  keys  sorted 
out 

Minimal 

Not  key  QA 


Adolescent 

Older  standard,  not  supported  widely  in 
commercial  products 

Adolescent 

Older  standard,  not  supported  widely  in 
commercial  products 

Adolescent 

Older  standard,  not  supported  widely  in 
commercial  products 

Adolescent 

Older  standard,  not  supported  widely  in 
commercial  products 

Adolescent 

Older  standard,  not  supported  widely  in 
commercial  products 


Adolescent 

Older  standard,  not  supported  widely  in 
commercial  products 

Adolescent 


Older  standard,  not  supported  widely  in 
commercial  products 

Adolescent 

Older  standard,  not  supported  widely  in 
commercial  products 

Adolescent 

Older  standard,  not  supported  widely  in 
commercial  products 

Adolescent 

Older  standard,  not  supported  widely  in 
commercial  products 


May  change  since  it  is  security  related 


Adolescent 

Older  standard,  not  supported  widely  in 
commercial  products 

Adolescent 

Older  standard,  not  supported  widely  in 
commercial  products 


Impact  Average:  0.08 


Maturity  Average:  -0.08 
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